What is parity? This category is designed just for features that exist but work one way on one platform, and another way on a different platform. Bugs are not parity! Items in snapshots and betas are subject to change so please be sure to only post about things that are currently released in Minecraft. Please read the intro post before you post!

← Parity
6
Follow

Revisit version numbering for parity

The newly announced version numbering still means that the version number for Bedrock and Java is significantly different, which makes communication in the community unnecessarily difficult between the player bases.

I'm not well versed in what goes into these version numbers so I don't know what's possible or not, but my suggestion is the following:

Java remains the same with 26.1.1, 26.1.2, etc to 26.2.

Bedrock maintains the same major version numbering but like so: 26.1.10, 26.1.11, ..., 26.1.110, then updates to 26.1.20 for the mid-cycle updates.

This would significantly streamline communication within the community and remove the unnecessary complexity of Bedrock incrementing twice as fast as Java.

Avatar
Registered User shared this idea

4 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 1
    Registered User commented
    Comment actions Permalink

    If mojang is going to insist on versioning with the year, this is the way to do it and not cause confusion talking about bedrock vs java. I don't understand why they don't just make the first number what is currently the minor version number instead of the year though and just update it instead of having that second number. The year number is basically meaningless. Versioning by year feels like it just happens to change because another year went by, not because meaningful changes were made.

  • 1
    Registered User commented
    Comment actions Permalink

    It could also work for bedrock:
    26.18 -> 26.19 -> 26.1A -> 26.1B .... for extreme cases where a drop needs more than 10 bugfixes yet still simpler than 1.21.124

  • 0
    Registered User commented
    Comment actions Permalink

    They could also go full ubuntu and go with the format "YY.MM.HOTFIX" with the year and month being when they start development for next version. Still would be a little confusing with the mid-cycle updates, but less than their current plan. Java versions for this year as an example would jump around like 25.01.0 -> 25.04.0 -> 25.07.0 -> 25.10.0 and bedrock would go 25.01.0 -> 25.03.0 -> 25.04.0 -> 25.06.0 -> 25.07.0 -> 25.09.0 -> 25.10.0, then the java and bedrock versions would match at least most of the year and end of the year update like the mounts of mayhem would be 25.10.0 for both versions instead of 25.4 for java and 25.70 for bedrock

  • 1
    Registered User commented
    Comment actions Permalink

    Exactly! Personally, I do not care what system or numbering they go with (though I do appreciate removing the "1." from the start, as it's meaningless if it never changes for years). I just want them to, as you said, finally make both version numbers the exact same between Java and Bedrock. It's so confusing to remember "this update/number is for Java and this is for Bedrock" when it could literally just be one number for our sanity and parity! And as you said, it'll make it easier for update discussion than for us all to ask "Java or Bedrock? And what update do you mean?". So confusing! Please Mojang!