The QSL 1.19 dilemma

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.

3 Likes

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.