Adventure 5.0

[kezz]

We're coming up to 5 years since the initial release of Adventure 4.0 and it's about time for us to think about a new major version release to Adventure 5.0. This issue documents our goals for a 5.0 update, as well as clarifying what our non-goals (i.e. things that we do not want to do).

Goals

• Cleaner codebase with a modern Java version. For reference, we currently run on Java 8. We will likely bump to the latest LTS version of Java at the time of Adventure 5.0's release.
• Removal of the many deprecated methods we've been stuck with over the years. This includes old Minecraft features that have reasonable modern replacements.
• Clean up of the API to remove duplicated methods that do the same thing, e.g. component constructor methods. These will require a recompile as ABI/API breaking, open for discussion on this.
• A seamless update with zero code changes for developers not using deprecated methods.
• Remove the extra-kotlin module. It doesn't follow good Kotlin practices and tying it to our monorepo means we can't easily version it to follow Kotlin releases and updates. It should, if we intend to maintain a Kotlin extra module, be split out into a new repo with independent versioning that can follow Kotlin releases.

Non-goals

• Changing the package. We don't want to do any giant changes so we're aiming for a seamless update for those not using deprecated code.
• Renaming things. We've already done all the renaming that we could want already with said methods being deprecated for a long time.
• A complicated update for developers. We want a migration to be as smooth as possible for developers, only requiring the removal of deprecated methods and potentially a recompile.
• Removing support for old Minecraft versions. If there are replacements that can reasonably be converted behind the scenes then I'm happy for us to remove said features (e.g. old vs new translation arguments), but otherwise we may be keeping some of these deprecations around if people are using them. Open to discussion though.
• Staying on Adventure 5 for another half a decade. I'd like us to do more regular major version changes if we need to - keeping stuff around for as long as we have done already is probably a mistake.
• Removing the legacy serializer. Despite it being recommended that you do not use legacy serialisation, we do not intend to use it as it is still useful for certain contexts that do not support components or for migrating legacy text.

What's next?

Please let me know your thoughts, even if it's a simple thumbs-up react and moving on. At this stage nothing is committed and we are open to any changes, additions, things you want to break but haven't had the balls to suggest, etc. Our current timeline would be to aim to release Adventure 5.0 with the next "major" Minecraft release (i.e. 1.22). If we don't have any changes to make within the next few weeks we will begin work on Adventure 5.0!

[Leguan16]

Major in terms of the next game drop or 1.22?

[kezz]

Major in terms of the next game drop or 1.22?

1.22 yep.

[exzolink]

Isn't 1.22 is synonym for half a decade now?😂

[Gypopo]

Will the LegacyComponentSerializer be removed?

Currently we use it to format MiniMessage into legacy color codes, and the other way around to keep supporting spigot(legacy color codes) instead of only supporting MiniMessage. As I think alot of people still use legacy color codes compared to MiniMessage.
And we are not ready yet to remove legacy color codes in our plugin.

[kashike]

LegacyComponentSerializer will not be removed - it will be sticking around for the 5.x lifecycle.

[kezz]

Will the LegacyComponentSerializer be removed?

No. We do not intend to remove support for legacy serialisation, despite it not being recommended for use. In your case, use adventure-platform-bukkit for spigot support so you don't have to use the legacy serializer.

[ajgeiss0702]

What java version is being considered? IIRC minecraft doesnt even run on the latest LTS, so bumping to that seems odd

[emilyy-dev]

Minecraft runs on Java 21 which is the latest LTS, Java 24 is not

[ajgeiss0702]

Minecraft runs on Java 21 which is the latest LTS, Java 24 is not

Ah, sorry my mistake

[Leguan16]

LegacyComponentSerializer will not be removed - it will be sticking around for the 5.x lifecycle.

LegacyComponentSerializer Has some valid use cases IMO. Like sign formatting for example.

[masmc05]

Could separating Sound.Type from Keyed be considered for 5.0?
If we look into an adventure platform, paper api, we could mainly see 2 reasons with the Sound interface, which is an api representation of a SoundEvent:

1. Inline sound events do not have keys, as they're not registered in any registries, but they do still reference a sound that may be registered on the player in sounds.json of a resource pack.
2. Currently vanilla does match the registry key of SoundEvent with the referenced sound from the resource pack (SoundEvent#location, sound_id field), but it doesn't seem like a requirement for the SoundEvent. So it has the possibility that vanilla one day may register 2 sounds with different ranges but reference same sound, making the api Sound object play incorrect sound due to the key being different from referenced sound.

[kezz]

LegacyComponentSerializer Has some valid use cases IMO. Like sign formatting for example.

Signs have supported components since 1.8.

Inline sound events do not have keys

I'm unsure exactly what you mean by this. All sounds have keys, whether they are "inline" or not based on the namespace the sounds.json is defined in, with the vanilla sounds existing in the Minecraft namespace and having minecraft as the key.

Currently vanilla does match the registry key of SoundEvent with the referenced sound from the resource pack (SoundEvent#location, sound_id field), but it doesn't seem like a requirement for the SoundEvent

I don't believe this will be an issue in the future, but I'd rather cross that bridge if we come to it then preempt what would be a rather odd design decision from Mojang by making Sound.Type effectively a useless dummy interface.