According to Semantic Versioning, the "patch" version, should only be incremented for backward-compatible API changes. Recently, Mojang has decided to introduce more significant changes in patches, i.e., the upcoming 1.19.4.
Issues with the current versioning method
- Now, both QoL updates and patches use the "patch" version; this defeats the purpose of separate version numbers. Consequently, there is an increased demand (by mod users) for modders' attentiveness to updating their mods as they aren't automatically clued in to the significance of the changes of an update.
- Suppose Mojang announces that the next patch version will contain features, but a major bug is discovered in the latest release. In that case, a patch will need to be issued under the version name previously announced as a content update.
- The major version, 1, has remained unused for versioning the game throughout its existence. I suggest that the 1 is dropped from the versioning, so the current "minor" version becomes the "major" version, and a new "patch" version is added. (ie 1.20 becomes 20)
Criticisms of this approach
- It may be confusing to players.
- Minecraft is not an API, so it does not need to be versioned as such.
I would respond to these criticisms by saying:
There is already the potential for confusion; this may be confusing initially, but not for long. There is also some precedence for this when Java went from 1.8 to 9.
Minecraft is used as an API by the modding community, so this change would benefit them.
Please sign in to leave a comment.
2 Comments