Currently, WordPress uses a incrementing numeric versioning system. XX.YY.ZZ could be read as ma.jor.patch which means version 4.8.1 can be read as version 48.1.
At the 2017 community summit, someone suggested that as WordPress project moves towards 5.0, that after 4.9 the versioning system should switch to semantic versioning by multiplying the versioning number by 10. This would mean the next version number after 4.9 woudl be version 50. The idea was shot down because if an end user is on 4.9 and then all of a sudden see the next version of WordPress was version 50; they would wonder where version 5-49 will freak out.
I propose that at the point of 4.9 we switch to semantic-like versioning.
Semvar is designed to be
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Since WordPress has a don't break backwards compatiblity mentality, it would not make sense to follow the Semvar 2.0 spec.
Instead I propose something similar but in WordPress terms.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR - New Feature : when there is a major feature change,
- MINOR - Bug Fixes : when you add scheduled bug fixes in a backwards-compatible manner, and
- PATCH - Security : when you make security fixes in a backwards-compatible manner.
It would mean that 4.9 is a minor changes from 4.8 and does not require any major feature releases. It would also mean that until there is a major feature change, version numbers can keep increasing as minor updates. This would mean until the next major feature drop, bug fixes and gardening releases can be scheduled in a timely manner in versions 4.10.0, 4.11.0 etc release cycles.
It would also mean that we can wait till a large feature drop before upping the versioning number to 5.0 and then from then onwards any major feature drops or breaking changes can pulled into the next major versioning number.
After throwing this idea around with a few developers to see what the inital reaction would be, some developers have asked whether it would mean that we would never get to 5.0 because major = breaking changes. I disagree that a major release has to be a breaking change. From my understanding of semantic versioning methodlogy, we should be able to define what major, minor and patch means to the WordPress team and run with that.
Notes from some pre-reviewers Adding ehre so i caont lose them/
The Chrome/Firefox model seems like the best approach at the moment, which is to say, “5.0, 6.0, etc.” Breaking changes can happen in any version, or not. I’d also say that, for your post, I wouldn’t describe the 4.9 -> 49/50 proposal, but instead mention the basics of 4.9 to 5.0 and on to 6.0 and beyond.
Simplifying has to be for a user reason primarily, so make the argument that simplified versioning allows users (and developers) a better understanding of how the WordPress release cycle works. 4.8 is just as “major” as 4.7 and 4.0 and 5.0 and beyond. Sell that argument and moving to 6.0, 7.0, etc, is much more reasonable.
We wants to get to a point where the version is just in the background and not super important, similar to Chrome.
Similar to Chrome meaning that for the most part, you're always on the latest update, which could have been deployed a week ago, earlier today, etc.