The QSL 1.19 dilemma

Quilt Development
1

Hello everyone!

1.19.3 has been quite the unexpected update in the 1.19 update series, and it’s causing us a bit of a headache with QSL.

Let’s sum up the update really quickly:

  • 1.19.3 is a 1.19 “minor” update.
  • Internally 1.19.3 has seen several refactors (registries, JSON-only world-generation, etc.)
  • Mojang announced a new release scheme (minors having more refactors and also experimental toggles instead of using longer snapshot cycle). For players it’s not supposed to change much aside from pushing sooner bug fixes, but for modders this has big implications (minor versions are less likely to be compatible for mods now).
  • Several modders seem to be split between supporting 1.19.2 or 1.19.3 (cf the Forge poll: “The 1.19.2 Dilemma”).
  • The 1.19 update series don’t seem to be finished as we can see with 1.19.4.

At Quilt we have the Quilt Standard Libraries, a.k.a. QSL, and it’s very version-dependent due to its nature of being a modding API that interacts directly with the Minecraft code.
So far its 1.18.2 version is discontinued (only receiving critical updates), the 4.x-series of QSL is targeting 1.19.2 and the 5.x-series of QSL is targeting 1.19.3, at least at the moment.

At the QSL team, we’re a bit torn apart. Usually in such occurences we would only support the latest minor release along with the latest minor release of the previous major version (which we haven’t done with 1.18.2 due to Quilt being in beta and the team having faced availability issues).

So we discussed a bit, and went on an idea of supporting both 1.19.2 and the latest 1.19 minor version. Though, this is a bit more complex and we clearly cannot decide that for ourselves. That’s why this post exists, we need feedback and now what version to focus our efforts on.

Here’s some ideas we’ve found already:

  • Maintain 1.19.2 and latest minor version of 1.19:
    • Focus main efforts to 1.19.2 (as-in PRs for 1.19.2 first, then port to latest, and get updates for 1.19.2 first too)
    • Focus main efforts to latest (as-in PRs for latest first, then backport if applicable to 1.19.2, and get updates for latest first)
    • In both cases 1.19.2 would be maintained but not the latest 1.19 minor version once 1.20 comes out.
  • Get a bit risky and give up on 1.19.2 and make 1.19.3 the QSL “stable” version. This would mean support for that version until 1.21 comes out as we would like some kind of 2 stable versions maintained at the same time, which in this case could mean 1.19.3 and 1.20 once it’s out.
  • Only maintain for the latest version while Quilt is in beta.

If you have more ideas please throw them in the thread!

I’d like to also note that, despite the annoyance the refactors 1.19.3 may bring to modders, it cleaned up several parts of the codebase, made data-pack resource loading less jank, and improved performances (especially load times).

Before you go add a response to this thread, I’d like to give some pointers on how to respond to such post: please specify your point of view (like, are you talking as a player? a modder?), this will help both parties to understand where interest lays.

We’re pretty excited to see what will come out of this discussion, so get to your keyboards!

3 Likes
2

Afaik, 1.19.2 API is in a pretty stable state.
Id be fine with it going to a similar state as 1.18.2 and only receiving bug patches, and maybe smaller, easy to port APIs. Its got a good surface and, imo, I dont think people will be stuck on 1.19.2 for too long.

1 Like
4

My stance has been consistent throughout the years: for new code, always target the latest version first. The rationale is that you will have to forward-port it eventually anyway, after all - “buying” a little bit of update time is usually not worth the additional workload that causes; my stance is that it’s better to use that time to implement new features, as the community always moves on eventually and will thus get to benefit from more new features total.

As an example: Nobody really remembers anymore that BuildCraft made the bold and generally disliked move to skip 1.10.2 and write new code straight for 1.11; however, I can assure you that this saved us a lot of development time due to not having to re-audit essentially all item stack-related code (and there’s a lot of it in BC) for a 1.10->1.11 update.

While I’m not familiar with 1.19.2/1.19.3’s exact dilemma (I’m only here because this popped up on my Twitter), what I would do is (a) new features/major improvements/etc. always for latest first (I mean, FAPI’s initial plan was to literally track snapshots for new features), backports if someone opts to put in the effort; (b) bugfixes for latest or both depending on severity/impact.

10 Likes
5

I would just give older common minors such as 1.19.2 a temporary support window of a few weeks (or versions) to let the modders migrate to the newest. A little like the Fedora support system. The newest should be the most supported, like how i was against MC Forge continuing to support 1.19.2. The future change in 1.19.x are going to likely be building on top of 1.19.3 and 1.19.2 will likely become more of a version in the dust as time goes on. And considering how mojang was going to be making lots more breaking minors it does not make sense to have long stables for each of them. Supporting both can take extra time so should not be held on to for that long. In anycase, 1.19.2 should not really get too many new features, instead you should just make QSL 1.19.3 and newer have features to make porting mods to newer version easier and possibly provide extra hooks to make it so breaking changes like these are not as applicable (at the expense on some platform lock).

6

Many mods will not be ported yet, but sticking to old versions which are much different from the future is going to slow down. A better solution may be for QSL to have their own ways to do registry changes to make it easier to port to 1.19.3. 1.19.3 snapshots were rough so it is understandable that quilt would not have gotten to much considering it was still new, in newer versions i would like to see quilt have more tools during snapshots to make porting eaiser.

Also, I have said this before with MCForge, but I think if you are going to have long term support versions based on what many mods are on, it would make sense to do it on a popular final major (like 1.18.2) since they are likely to have more good mods for future play and are much different internally than 1.19.x meaning many mods would take a long time to port and could just skip 1.19.2 and modders may need 1.18.2 support for longer. So if 1.18.2 does not have strong support outside of bug fixes, there is little reason to do 1.19.2

7

The problem is with a lot of these changes, its more like making a library for two major versions of minecraft, especially as the splits get larger. No features would be removed from 1.19.2, only new features would be added to 1.19.3+. Obviously bug fixes would be made for 1.19.2, but new features wont be added to 1.19.2.

1 Like
8

I agree with Asie here; supporting the latest version makes the most sense. I think a grace period of one-two months is fair, but mods should be expected to keep up to date.

3 Likes
10

Many mods are using 1.19.3 as a transition or as their main already, 1.19.2 is not getting many new mods, mostly just updates for mods that have not updated versions. (or support more than 1)

11

And considering how mojang was going to be making lots more breaking minors it does not make sense to have long stables for each of them.

I think some part of the plan would be in the future to consider the first release of a major version to be the go to for stable modding, and have stuff on latest.

The big issue is a large part of mods are now kind of depending on where the bigger mods are to know if it’s worth to port or not, which is kind of why this dilemma is there in the first place.
I am tempted to just get rid of 1.19.2 but I’m severely concerned about it becoming the go-to version for 1.19 modding, making getting rid of it a potential mistake.

1 Like
12

I personally strongly dislike the “first is stable” idea, because we could easily have 1.19 with security issues, or just a buggy release. Doesnt seem fair to pin modders and mod users to a version just because it was first.

1 Like
13

please stick to latest minecraft for new code. backports are good and I fully support working to backport new apis, but their initial version should always be on the latest minecraft version.

1 Like
14

After thinking about it for a little while i did kind of agree with it to an extent, because while some mods versions can have many breaking minors (like how 1.19.1 and 2 broke some 1.19.0 mods) i think if mojang will continue to break mods in minors they will need some kind of a base in the newest major. Though if they decide to support the previous like it kind of sounded like they also want to do it could mean QSL needs to support 3 versions mainstreamly.

15

Of course there would be exceptions if there’s security issues or massive bugs, I wouldn’t want to pin people on a bad or risky release.

1 Like
16

It’s better to stay up-to-date with the latest release and the last minor release, but the fact Mojang is removing snapshots is a little weird, especially because they’ve been doing it for so long. Only recently has Mojang really started picking up the pace in releasing breaking changes for Minecraft.

2 Likes
17

As a toolchain developer in general as well as a modder myself? I believe that we should have some level of support to the established slightly-older version if we can reasonably support it, however, with this recent change of pace and the problems of having the older version be the target of new APIs? I feel like it’s time to shift main development to the latest, with backports to older versions if people are willing to work on.

We can’t treat developing nor backporting to an older version as a costless action, with an example being how the Resource Loader improvements got stuck at 1.19.2 for quite a long time and only recently it got updated to 1.19.3; People don’t always have the free time or motivation to replicate the same code to another version, and that’s understandable, however, in comparison, Chat API being stuck at 1.19.3 with no 1.19.2 backports yet is much less painful than having something new stuck at an older version and having to eventually port it in a painful process;

Another important thing to consider is that our toolchain in general is pretty targeted on the latest version; Sure, we maintain two branches of QSL and QLoader is version-agnostic, but Quilt Mappings has practically moved on to 1.19.4 snapshot updates, with maybe some 1.19.3 backports there and there; That already makes backporting harder when a certain area wasn’t updated on 1.19.2 but was on 1.19.3; QM does plan to become version-agnostic, but those are plans, and expecting those to be finished anytime soon is pretty unrealistic

So, what I say is that the latest version should always be the target for QSL, although we should always have one version that we may backport improvements and fixes to when possible and when we have the developers to do it, but I feel like it shouldn’t be mandatory anymore; It is worth it to wait a bit longer to backport if needed instead of constantly sacrificing yourself to it

2 Likes
18

Version Agnostic QM sounds like it would be good

19

1.19 didn’t follow a new schedule, 1.20 probably gonna be just 1.19.5 with hidden content enabled so it’s most likely to be very stable

20

The thing is, 1.19 is in an awkward position, because Mojang decided to make this major shift in development in the middle of an established update cycle. I doubt many people were expecting 1.19.3 to exist, not to mention 1.19.4 and, potentially, more. As such, a big chunk of players settled down on 1.19.2 and that’s where you’ll find most of the mods for 1.19.x. With how Mojang plans to keep moving forward, it made little sense for many modders to jump straight into porting to 1.19.3, so you can observe a roughly 70/30 split, where 70% of 1.19.2 mods haven’t received an update or keep supporting .2 and .3, and 30% just completely dropped .2 and moved onto .3 (or were developed for .3 to begin with). In that state, that leaves us with mods, that are still going to stay on 1.19.2 and mods, that now have to decide whether they move onto 1.19.4, drop .2 and support .3 or drop .3 and support .2. Alternatively, of course, only support the latest. In my opinion, as a player, who enjoys making and maintaining modpacks, it’s best to keep supporting .2, due to its established playerbase and otherwise target the latest release. Is it painful? Yes, however, I don’t think this is going to be the new norm.

With 1.19 being an odd one out, the modding community fell into a bit of chaos, but now that we can reasonably expect at least 5 minor versions per major release, people aren’t going to settle down on any minor version in between .0 and whichever ends up being the last. This should make 1.20+ a lot more bearable, as we can reasonably expect support for each minor version, but LTS only for its final one, as there won’t be anyone settling down on 1.20.2, knowing full well 1.20.3 is around the corner.

So, what about 1.19, then? I say keep targeting the latest minor version for development and main support, and give 1.19.2 a special treatment in a form of backporting all the applicable fixes and features to it. This will ensure, that the already established modding scene remains alive, but the development won’t be hindered by having to work with older version first and then updating. And whichever ends up being the last minor release won’t suffer from being underdeveloped, so shall the modding community collectively move onto it, things won’t be miserable.

1 Like
21

Gonna be honest, I personally dislike sticking to 1.19.2 as it’s on a technical level much more jank, 1.19.3 eliminated quite the amount of patches required to make mods happy with the game in QSL and I feel like being able to take advantage of that would be preferred.

5 Likes
22

Kinda surprising 1.19.3 would have less patches , but that’s good.
1.19.3 has already been out for a while and people have already had a lot of time to move their mods over and 1.19.4 is on the horizon, so I think supporting 1.19.2 for much longer beyond bug fixes will simply be a waste of resources that can’t be used elsewhere while 1.19.3 code could be used in 1.19.4 and newer, especially since you said 1.19.3 was easier to develop. Maybe you can just continue to support 1.19.2 until 1.19.4 comes out, so then you can keep the 1.19.2 people happy for a while and give them more time while making it temporary so you can focus on newer versions. I strongly doubt 1.19.2 will become the main 1.19 version as historically middle minors have not become the dominate version, such as in 1.18.1 or 1.16.1 or 1.7.2 and 1.6.2 even