A proposal for changing the WordPress versioning scheme


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 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.


3 Replies to “A proposal for changing the WordPress versioning scheme”

  1. Although I am generally in favor of semantic versioning, I don’t think this is something WordPress should even consider.

    IMO implementing one’s interpretation of SemVer (instead of strictly sticking with it) is way worse than just having a distinct versioning scheme and making clear what it implies and entails.

    Incidentally, I have just written on the topic of SemVer and WordPress: https://alexandergoller.com/semantic-versioning-wordpress-userland/

  2. @jeffpaul: The immovable object that is “Gutenberg in 5.0” is banging up against the WordPress versioning scheme (ie there won’t be a 4.10.0 release). The situation we’re in now — three weeks before the 4.9.6 release — is that an update with a number of new enhancements and features (https://make.wordpress.org/core/2018/05/03/wordpress-4-9-6-beta/) is being treated as a bugfix / security patch and will auto update whereas, previously, this would have been a major update (eg 5.1 to 5.2).

    I agree that it shouldn’t be called SemVer, call it WPVer and be done with it ☺️, but any versioning scheme no matter what it’s called needs to be consistent and the WordPress versioning scheme is now inconsistent. It’s effectively “WP 5.0 contains Gutenberg and 4.9.x releases contain everything up until then” — something needs to give.

Comments are closed.