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).
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
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.
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.
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)
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.
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.
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.
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.
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.
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.
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
Version Agnostic QM sounds like it would be good
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
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.
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.
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
To be honest, I don’t really like the claim that it has been enough time since 1.19.3 for mods to have ported over. Due to the time of year, some regions may result in mod authors having a lot of work.
And I’ve been one of the victims of the “hey here’s too many projects that will be graded” resulting in only a low amount of my mods to be ported. Especially considering this is not an easy update to make for some mods.
I hope 1.19.4 will be easier to deal with to hopefully not make modders shy from updating.
In the case that a major version increase ends up being little more than enabling the dev datapack by default, there won’t be much reason to stay in 1.19.whatever, when porting to 1.20 is trivial.
Thus, maybe it could be possible to have a version change whenever porting from the previous version is bound to cause plenty of breakage… though that would have the problem that you won’t be able to know that until the first snapshot/prerelease/whatever.
I’m not sure if I explained it very well, so here’s a table
(bug report: can’t make tables with markdown [probably intended] or bbcode [probably not])
(also if this appears as tag soup, blame tag ommision, i’m not writing a trillion close tags)
| 1.19 | Heavy breakage, new version. |
| 1.19.1 | Minor breakage, replaces 1.19 |
| 1.19.2 | Minor breakage, replaces 1.19 |
| 1.19.3 | Heavy breakage, new version (Does NOT replace 1.19) |
| 1.19.4 | Minor breakage, replaces 1.19.3 |
| 1.20 | Mild breakage, but not enough to warrant a new version |
| 1.20.1 | Minor breakage, replaces 1.20 |
| 1.20.2 | Heavy breakage, new version (Does NOT replace 1.20) |
| .. | Stable versions are 1.19.2 and 1.20.1, with 1.20.2 as rolling release. |
There’s probably a very good reason why this is A Bad Idea, though…
EDIT: oh GOD 2 months!? I suspect y’all already have an answer and this necropost is useless…
Not useless, its a useful insight.