Versioning, Sodium LTS and minor version breakage

[Madis0]

First, let's start with some facts:

• Since 1.19.3, Minecraft minor versions break mods more (not sure why the article is deleted now)
• Fabulously Optimized 4.6.0 (1.19.3) took a record-breaking 3,5 months to get stable (ensure all mods are there), this happened again with 5.8.0 (1.20.4) and may happen in the future
• Since 1.20.1, Sodium (and seemingly Iris) are doing LTS (long-term support) versions
• Fabulously Optimized supports SemVer since 2.1.0, with the following logic:
  • X.Y.Z stands for major versions which directly map to Minecraft's 1.Y.Z (1.16 was 1, 1.17 was 2 etc)
  • X.Y.Z stands for minor versions which may map to Minecraft's 1.Y.Z or just refer to bigger changes like added mods
  • X.Y.Z stands for patch versions - no breaking changes, no mod additions/removals

Therefore, more than ever it could make sense to:

• Change its versioning logic
• Backport FO more often/regularly
• Release stable versions faster with more removed mods (that didn't make it)

However, there are obviously caveats:

• With current semver logic, updating version 5.6.x (1.20.2) for example means I cannot change mods and do big changes. Making a 5.7.x release would confuse it with the 1.20.3 version, similar to the shift that happened with 5.4.0. Surely, it is an artificial limit but it is a limit nonetheless.
  • One proposal is to make future versions change major versions, such as 1.21 being 6.x.x and 1.21.1 being 7.x.x. That sounds nice in theory, but in practice:
    • What if 1.21.1 ends up being a very minor release with almost no changes?
    • What if 1.21.0 will never become stable but instead will be superseded by a later version?
• Since the Sodium LTS change happened, people asked if FO will do backports (to it and 1.20.1). Right now, it doesn't make sense:
  • In both 1.20.1 and 1.20.2, the breaking changes of Sodium would definitely break other mods that users like to add.
  • In 1.20.1 Sodium Extra, Reese's Sodium Options and Indium are not up to date with said Sodium version, which would severely cripple several aspects of FO.
  • Sodium will soon bundle Indium's main feature and do some kind of UI change similar to Reese's Sodium Options, so the best bet is to just wait.
  • https://github.com/Fabulously-Optimized/fabulously-optimized/issues/219 can also still happen, just don't know when and how.
• I've considered releasing FO 5.8.0 without CIT Resewn, because it has not updated yet. 5.8.0 was released with a fork, 5.9.0 released with original mod
  • There is at least one working fork, but it is not (yet) possible to upload it to CurseForge. I have no plans in discontinuing CurseForge edition, nor creating another split between CurseForge and Modrinth versions - closing that gap took a long time already.
  • If I do not wait for CIT Resewn now, where should I draw the line (time to wait for updates and mods to wait for) in the future? Previously Continuity was holding FO 4.6.0 back, but both of these mods provide "essential" OptiFine parity.
• Any backports require my time and energy.
  • If the changes are not trivial, it could hurt FO's update rates in general.
  • Or, similar to current state, the backports would not necessarily be released in equal times as the latest version.
  • There is also a matter of diminishing returns - at some point the majority of users just stop caring about old versions, and that is the idea that I want to promote anyway - latest is the greatest.

I'm open to suggestions on what to change about FO's schedules and versioning. And as mentioned, any major versioning/backporting changes are planned for 1.21/6.0.0 at the earliest, no 1.20.1 backports are planned at this time.

[TheBossMagnus]

Some IMO points:

In both 1.20.1 and 1.20.2, the breaking changes of Sodium would definitely break other mods that users like to add.

One thing that (could) be done is to update only non-breaking changes (only fixes or minor features), as LTS works in Linux. This would reduce the effort needed but it's a compromise and goes against the latest is the greatest

What if 1.21.0 will never become stable but instead will be superseded by a later version?

I don't se the issue here

I've considered releasing FO 5.8.0 without CIT Resewn, because it has not updated yet.

I think the issue is not in the versioning itself, but in the criteria used to define the stability (alpha/beta/release). In Modding sometimes happens that it's not clear if a mod will get updated and when. Another case of this is been colormatic, and it has been skipped. I propose to define the status by thinking about the stability itself. If a not crucial (like sodium, iris -a list might need to be done-) mod is missing, it shouldn't be blocking the switch from beta to release. Obv the absence of features shall be mentioned in the changelog, always. Surely a more subjective solution, but also more truthful.

Any backports require my time and energy

That's completely on your own, but i believe a significant amount of players (roughly 58% rn aren't using 1.20.4 nor 1.20.2

In conclusion/TLDR:

• The versioning probably needs to be changed, how needs to be defined
• I think the alpha/beta/release labeling needs to be revised
• Backports would be good, needed to check firstly feasibility (How sodium LTS will go and the effort-result balance) and secondly the way it will work
• I believe that having some public docs to describe how all of these internal changes will work is needed. For the development to be coherent and for the users to understand how and why things are done
• Maybe involving the community has been done with the vote for the removal of some mod. Maybe do not relay too much on numerical votes and more on the discussion itself.

[Madis0]

Good points, thank you.

One thing that (could) be done is to update only non-breaking changes (only fixes or minor features), as LTS works in Linux. This would reduce the effort needed but it's a compromise and goes against the latest is the greatest

True, but if the changes are too minor (like 3 mods with minor changes), then the effort doesn't necessarily justify the update for me or the players.

What if 1.21.0 will never become stable but instead will be superseded by a later version? I don't se the issue here

The issue I meant is that like when FO "skips" (or actually skips) over a major version for seemingly no reason. Not really a user-facing issue I guess, just weird to look at.

I think the issue is not in the versioning itself, but in the criteria used to define the stability (alpha/beta/release). In Modding sometimes happens that it's not clear if a mod will get updated and when. Another case of this is been colormatic, and it has been skipped. I propose to define the status by thinking about the stability itself. If a not crucial (like sodium, iris -a list might need to be done-) mod is missing, it shouldn't be blocking the switch from beta to release. Obv the absence of features shall be mentioned in the changelog, always. Surely a more subjective solution, but also more truthful.

The thing is that Colormatic:

• was always less visible to users than connected textures and custom items
• was knowingly hard to forward-port after attempts from several devs - in contrast to CIT Resewn, which has already been ported by two

That said, if the update won't happen soon, then I'll likely do it anyway.

That's completely on your own, but i believe a significant amount of players (roughly 58% rn aren't using 1.20.4 nor 1.20.1

I see 46.8% of users using 1.20.4 in the "Minecraft Version" graph, so I'm not sure what you were referring to.

Edit: lol, I completely missed your point and the number is actually 34.6% that do not use either. 77.5% of users do use 1.20.x, with 1.20.4 being the most popular by now.

Maybe involving the community has been done with the vote for the removal of some mod. Maybe do not relay too much on numerical votes and more on the discussion itself.

Yeah, I usually prefer discussion over votes. Although for some mods a complete removal is not even necessary, I could just remove it now and readd later (like how it has happened with EBE many times) - it's more of a matter of meeting expectations and keeping the UX similar across stable versions.

[osfanbuff63]

What if 1.21.0 will never become stable but instead will be superseded by a later version?

I don't se the issue here

The issue I meant is that like when FO "skips" (or actually skips) over a major version for seemingly no reason. Not really a user-facing issue I guess, just weird to look at.

IMO, skipping versions when it's a change in the first few alpha versions for a quick path (like with 1.20, 1.20.3, etc) shouldn't be needed.

[Madis0]

I've been thinking about this and I could perhaps maintain 2 stable versions, e.g. 1.20.5 and 1.21.1. In the current versioning system that would be something like 5.10.0 and 6.1.0.

If I'd use major versions, things start to look weirder though - 5.10.0 and 7.0.0. Or, perhaps consider a situation similar to current status quo - 7.0.0 (1.21.1) and 10.0.0 (1.21.4). At some point the versions would be so far apart that it is very hard to grasp what is what - for example 5.10.5, 7.5.2, 10.2.3, 14.4.2.

Maybe I should map it to Minecraft versions to some extent?

• 21.1.0.0, 21.4.0.0
• 4.11.0, 5.10.5, 21.1.5.2, 21.4.2.3, 22.3.4.2, getting into Chromium territory here 💀

Some mods use something like a prefix, a la 1.20.5-5.10.0 or 5.10.0-1.20.5. But then is there really a benefit of continuing the number? Aka, what about 1.21.0-1.0.4, 1.21.1-1.2.4, 1.20.4-2.3.5?

Which all comes down to readability and comparability again...

[NebelNidas]

I'd bump FO's major version component only for compatibility-breaking MC updates:

• 1.16
• 1.16.2
• 1.17
• 1.18
• 1.18.2
• 1.19
• 1.19.3
• 1.19.4
• 1.20
• 1.20.2
• 1.20.3
• 1.20.5
• 1.21

See ModMenu's or ClothConfig's versioning schemes. To avoid confusion as to which MC version is targeted, I suggest appending this information as build metadata (e.g. +1.21), just like Fabric API.

[Madis0]

I'd bump FO's major version component only for compatibility-breaking MC updates:

• 1.16
• 1.16.2
• 1.17
• 1.18
• 1.18.2
• 1.19
• 1.19.3
• 1.19.4
• 1.20
• 1.20.2
• 1.20.3
• 1.20.5
• 1.21

See ModMenu's or ClothConfig's versioning schemes.

That system cannot really work for modpacks, every version can break some compatibility...

To avoid confusion as to which MC version is targeted, I suggest appending this information as build metadata (e.g. +1.21), just like Fabric API.

Not sure if that is needed, since the names already have them, but maybe.