1.19.3
Approximately 14 hours after the release of 1.19.3, Forge version 44.0.0 finished building and was released to the public.
It’s now available for everyone to use, play, and work on.
However, some warnings:
Breaking Changes
Mojang have done some MAJOR refactors this time around; it’s another 1.16.2, for those who know what I mean.
Everything from creative tabs, to asset loading, to stitching, was reworked.
A comprehensive list of the breaking changes (courtesy of OrionOnline) follows:
- Removal of Material Detection from baked models
- Automated loading of textures
- Updated handling of sprite contents in Textures
- New systems for handling CreativeModeTabs (No more extending, everything via the builder and relevant events)
- Refactored DataGen: PackOutput instead of DataGenerator, Async handling of holders and data generators which need them
- Vector and Matrix classes removed, all performance-critical maths replaced with JOML (Java Open Maths Library)
- Button constructor removed, moved to a builder (like Component was)
- Assorted changes to chat
Changes like this in a minor version update gives us a dilemma…
A dilemma
Having such major changes in a minor version is a hard barrier for mods.
Mods for 1.19.2 would require a significant amount of rewriting to work properly on 1.19.3, so there is an extremely small chance that mods would work across the version barrier.
That creates confusion; a modpack for 1.19.2 may accidentally include mods for 1.19.3 (and promptly crash, because the changes break it), or vice versa; a 1.19.3 modpack including a mod for 1.19.2.
Essentially, 1.19.3 should be treated, for all intents and purposes, like a new major version.
This leads to the dilemma: Forge’s LTS policy applies across major versions… so should it apply to this?
1.18.2 is in no danger of becoming suddenly unsupported right now, but we need to figure out where to focus our efforts, so we’ll ask the community:
Should we support 1.19.2 and 1.19.3 separately, as separate major versions?
We’ll hold a vote in a couple of weeks to figure out what the plan of action is.
If the vote says yes, they should be separate, then 1.19.2 will be forked out of our 1.19.x branch and maintained separately, by the LTS team. We’ll have a separate channel for it in our Discord server, and the forum team notified appropriately. 1.18.2 will enter a one-month grace period as we now have a latest and LTS version specified.
If the vote says no, nothing changes. No new branches, 1.18.2 stays our LTS, and we just carry on with 1.19.3. 1.19.2 will essentially be abandoned.
But wait, we’ve done this before, right?
What changed
1.16.2 was a long time ago. 2 years and 3 months, according to K9. Back when it was released, everything related to datapacks changed. Dimensions, biomes, save formats, features… trees…
It created a major rift in the versions, a huge incompatibility barrier that caused a lot of pain for modders and end users.
Our decision back then, was that 1.16.2 is a minor version, so we just continue as normal. Despite the major breaking changes, it’s not worth the effort to fork and do all the work twice.
That was a pretty unpopular decision.
This time around, we want to involve the community. If the modders who will be affected by this think it’s better to split off from 1.19.2, then we will. If the end users want all their existing 1.19.2 modpacks to still work and be updated a couple months from now, we’ll do everything we can to make that happen.
This time around, it’s all about putting the decision in the hands of the community.
Closing notes
No matter what happens, we’ll stay as-is for at least one month, to allow modders and modpacks to update to the new way of things. That means we’ll have 3 supported versions for a while, which is pretty stressful for us, so hopefully it all goes to plan.
