History
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.
Proposal
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.
Notes
- 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 methodology, we should be able to define what `major`, `minor` and `patch` means to the WordPress team and run with that.
- I know this is a far-fetch idea that will not be popular with many people, but if we were ever going to switch versioning number, I think this is a realistic method of doing so. Doing it now would mean that we don’t have to wait till WP5.0 before any more minor releases come out.
- I am sure there are many flaws in this idea that some people who are way more clued up with the WordPress versioning and rollout process can point out. Just remember its a proposal/ idea/ a dream. I’m ok with it staying just that.
- WordPress is not the only popular piece of software not on Semvar and it seems to be developers who care about the software versioning system of the project.
- If you want to read up more about different software versioning systems; Wikipedia is your friend.