DON'T change the version numbering system from 1.XX to YY.X!!!

1.XX isn’t broken. Mojang is fixing something that doesn’t need fixing, and the new 26.1-style numbers look like bad OS firmware. It’s going to make mod/texture pack/addon pages confusing and an eyesore when listing which versions it supports or whatever, it will also confuse players, and create an absolute mess. All launchers will look stupid when the numbers completely change and some people may even be confused as to which version is which, and will also just be an eyesore. Also, what happens in a few years if Mojang decides to go back to big, major updates? The new system doesn't account for major updates and Mojang will change the system again, therefore we will have 1.XX, YY.X and then a 3rd numbering system which will create a mess, and it’s going to be chaotic as heck. Whoever decided to change the numbering clearly didn’t think long-term. The 1.XX saga as we know it has been serving us well since Java Edition Beta 1.0. 'If it ain't broke, don't fix it', ingrain that into you.

The excuse that “1.XX makes players expect big updates” is weak. We haven’t had a true big update since 1.18, and players understand that most updates from here on out are smaller drops. The 1.XX saga has handled small and big updates fine, and I will prove it.

Examples (I am using Java Edition updates for reference)

Small to mid-sized updates that were basically drops:

• Beta 1.0 to Beta 1.7
• 1.0 to 1.6
• 1.10 to 1.12
• 1.15
• 1.19 to 1.21
• 1.21+ (which are literally drops)

That’s approximately 28 small/medium updates in the 1.XX system (includes small/medium sized updates and drops since Beta 1.0).

True big updates that Mojang claims the 1.XX saga was entirely for:

• Beta 1.8
• 1.7
• 1.8
• 1.9
• 1.13
• 1.14
• 1.16
• 1.17/1.18

That’s 9 numbers in the 1.XX system that were major big updates compared to 28 smaller updates.

Therefore, by accounting how many large updates were in the 1.XX system, the excuse "1.XX being for big updates only" is a complete load of utter rubbish when 28/37 (~76%) of content updates in this system are small/medium sized updates.

Mojang already made two messes with this system: one by skipping two versions on Bedrock to bring it in sync with Java (BE 1.14 jumping to 1.16) (though that was necessary and one of the only good messes Mojang have made with update numbering), and not jumping to 1.22 with drops and instead riding 1.21 longer than needed. Changing the system to YY.X just makes the numbering system messier and will create confusion if Mojang ever return to bigger updates.

Changing the numbering system is running from criticism that the next major 1.XX version might be a small update. Mojang, you’re scared people will expect big updates, so Mojang hide behind a new numbering system that isn’t future-proof and makes everything more messy instead of owning the situation and taking criticism. That annoys fans more than 1.22 being a small update ever would.

The truth hurts Mojang. It's time to get your act together. Mojang, it doesn’t matter how big updates are, but stop changing stuff for no reason! 1.XX works fine and changing the numbering system is already proving to be annoying and confusing. The old system didn't work because Mojang didn't let it work because they were panicking over nothing. If you started the first drop with 1.22, the community would be over the whole "each new number means big update" complaint. Instead, they pushed out the criticism for no reason and then changed something that isn't broken and they're getting criticism for it. So their whole plan to avoid criticism is not working. Stop running from the criticism Mojang and take it on the chin.

The version numbering system only needs a slight adjustment for clarity and flexibility. Hotfixes should use an underscore _XX after the main version (e.g., a hotfix for 1.22 would be 1.22_01 NOT 1.22.1), while content expansions of the previous drop use a .X suffix (e.g., 1.22.1, 1.22.2). Unrelated drops start a new main version number, so if the next update is completely unrelated to 1.22, it starts 1.23; if it is related to 1.22, then it starts 1.22.1.

If Mojang wanted to split large updates, let's say split an End Update, it follows the same rule as content expansions off of the previous drop: the first drop keeps the main version, and subsequent related drops use .X (e.g., 1.23, 1.23.1, 1.23.2). This also works for yearly large updates, while hotfixes still use _XX.

If Mojang went back to yearly updates, this system still works. They would just use 1.23 for the End update and have little or no content expansions and only

Snapshots change from the original {YY}w{WW}a confusing mess to a similar setup to the YY.X snapshot system. Betas/Previews can also follow this same logic, just tweak the numbers for how Bedrock works and replace 'Snapshot' with 'Preview' or 'Beta'. For example:

1.22-Snapshot_#1 = first snapshot for the 1.22 update
1.22_01-Snapshot_#1 = hotfix snapshot 1 for the 1.22
1.22.1-Snapshot_#1 = first snapshot for an expansion update upon 1.22
1.22.1_01-Snapshot_#1 = hotfix snapshot 1 for the 1.22.1 content expansion update
This slight change handles drops, expansions, split updates, yearly updates, and hotfixes while keeping the numbering system clear and consistent.

Mojang, do yourself a favor, keep the 1.XX system and tweak it how I suggested. It has worked perfectly fine since late 2010/early 2011. Call the next drop 1.22 and the one after that 1.23. This keeps things consistent, avoids future headaches, and keeps community content websites looking clean.