Use Semantic Versioning for releases

[netweb]

Via todays #core dev-chat: ​https://wordpress.slack.com/archives/C02RQBWTW/p1520470243000286

​Dion wrote:

4.10 instead of a 5.0 isn’t likely to work very well, other than the fact that it moves us from using decimal versioning to semantic versioning, I feel we might have some locations where we expect a branch is 3 digits, but that might not be the case. If it’s simply to avoid the 5 number because we’ve suddenly decided the first digit is actually special, then maybe it’s time to set a plan in place to adopt semantic versioning over the next few releases.

Background context: The question was posed, can a release numbered 4.10.0 be released as a major version instead of a minor version

What is Semantic Versioning?: Semantic Versioning is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. ​https://semver.org/

[Luciano Croce]

I consider this proposal very interesting'''

I am in favor of this introduction, but perhaps we should start from 5.0.0 in order to maintain the backward compatibility with the system adopting up to now with version 4.9+ and earlier.

[jdgrimes]

I am definitely a fan of semantic versioning, but I think it is important to realize that we can't just decide to change how we version core without some major implications. The update code currently treats 4.5.0 as a "major" release, and 4.5.1 as a "minor" release (core's terminology). Both of these effectively map to semver's "minor" release. There is no concept of a "breaking" release or a "patch" release, as semver defines them. The code in core (and probably any plugins/themes/etc.) that relates to core updates will have to be changed. But so will users' perception of what to expect from updates. In short, this would be a breaking change, as @Luciano Croce pointed out, so there is no way that there could be a 4.10.0 following semver. It would have to be a 5.0.0 that made the switch.

In addition, because core attempts to maintain almost-infinite backward compatibility, if we switched to semver WordPress would in theory always be on 5.x, because there would never be a breaking release to usher in 6.x. Of course, the reality is that core just ends up making little breaking changes all of the time, once it is safe to do so without much chance of actually breaking any code out in the wild.

In the end, what we would really be contemplating here would be a complete change of philosophy for WP in regard to versioning, backward compatibility, patches, minor updates, etc. Although part of me would prefer that core embraced semver, core has a somewhat unique situation in regard to its technical debt, scope, and diverse versioning audience, and there is wisdom in some of the philosophies that it has embraced here, which are not really compatible with semver.

TL;DR: semver is not just a way of specifying version numbers, it implies an entire versioning philosophy, and it runs counter to the versioning philosophy embraced by WordPress core. There is a lot that would have to be considered before a change like this could be made.

[pento]

Semver certainly has it's uses, and I'm absolutely in favour of it being used for new development (for example, the ​packages we release on NPM all use semver). It isn't a viable option for WordPress, however.

WordPress is a huge code base, with 15 years of history (and the years before that as b2!). We do occasionally make small breaking changes, but we try not to. As @jdgrimes mentioned, moving to a versioning system where we explicitly make breaking changes would be a huge philosophical change to how WordPress is built.

This is also in opposition of the ultimate goal of auto-updating all WordPress releases, not just the minor ones. Much like the version number of Chrome, or iOS, or Pokemon Go don't actually matter, neither should WordPress' version number matter: it mostly just needs to be an indicator of "this version was releases before/after that version". Trying to shoe-horn a versioning regime around that is an unnecessary restriction.

[eclev91]

I disagree with a couple takes here, and would like to see this ticket reopened.

a complete change of philosophy for WP in regard to versioning, backward compatibility, patches, minor updates, etc.

I don't think SemVer forces either of these things. A dedication to backwards compatibility is a philosophy, not a versioning system. A versioning system is simply a standardized means of communication that (and this is important) an automated system can understand.

Let's assume WordPress had never broken backwards compatibility. 5.6.1 would have, rather, been 1.39.1. And there's nothing wrong with that! SemVer doesn't care. With the block editor, we'd more realistically be looking at 2.6.1, but the point is that whatever number you arrive at, it's simply a result of your philosophy and practices.

moving to a versioning system where we explicitly make breaking changes

I would prefer explicit communication, myself.

This is also in opposition of the ultimate goal of auto-updating all WordPress releases, not just the minor ones.

I think SemVer would actually be a huge benefit to this process. Both technical and non-technical users should feel safe enabling auto updates for Z updates, and likely even Y updates (given X.Y.Z). Auto-enabling Y and Z updates out of the box would be a pretty safe decision. I'd argue, in fact, that the current "update everything" default is super irresponsible, especially since WordPress core can't attest to the integrity of third-party plugins and themes. Without SemVer, there's no way to implement an automated system somewhere in the middle.

I would even argue the opposite is true - not having SemVer, paired with the new auto-update system, forces WordPress core to never make BC-breaking changes (see the fallout during the WP 5.0 release - "why is my site broken!?"). With SemVer, avoiding BC-breaking changes is a (commendable) philosophy, not a requirement.

We do occasionally make small breaking changes, but we try not to

This kind of sucks. SemVer, and an auto-update system that was cognizant of it, would encourage core to collect these changes under the banner of a major (as defined by SemVer) release, which communicates pretty succinctly to plugin authors and technical site maintainers "Hey, you should definitely read the developer release notes." Right now, it's easy to fall into a trap of mostly ignoring core releases if you don't have automated testing set up.

Meanwhile, laypeople could opt-in to major release auto-updates, which should be few and far between anyway, because the WP release philosophy shouldn't change.

Much like the version number of Chrome, or iOS, or Pokemon Go don't actually matter

I'm not an iOS or Chrome extension developer, or an workstation provisioning manager in IT at an enterprise company, so I don't know this, but I assume those version numbers do matter to certain individuals. It's just obfuscated to everyday users. Not sure how SemVer precludes this from being WordPress's ultimate goal.

And finally, WordPress is clearly setting the precedent for plugin authors and their versioning system (see the recent backpedaling by WooCommerce on SemVer), which is all the more frustrating for technical site maintainers. With large numbers of clients and automated systems, the more risk I can mitigate in a one-click update process, the better. I shouldn't have to read the changelog for every plugin on every client site to know when it is or isn't safe to update.

Once again, for the lay-person, they can either opt into major auto-updates or just minor ones as a sensible default. You can even stick to the "Decisions, not options" mantra here. SemVer allows core to make a more responsible decision in defaulting to minor release auto-updates, and provide an advanced setting for users who want major updates as well (or who want to disable all auto-updates), just like today.

What's standing in the way of adopting SemVer? Sounds like some changes to core update logic and a consensus? Would love to hear more input.

[jorbin]

I would argue that the WordPress versioning system is essentially semver only the x has a dot in it and there is no z. 5.6.0 is version 56.0.

[eclev91]

In that example, does every release have BC-breaking changes, or does no release have BC-breaking changes? Because neither is true.

[jorbin]

There are breaking changes every release, only they are generally minor and planned out in such a way that the impact is low.

[jb510]

Replying to jorbin:

There are breaking changes every release, only they are generally minor and planned out in such a way that the impact is low.

I don't quite agree with this. Yes, breakage is generally minor, but not always.

I'm still suffering through broken things across many sites due to JQ deprecation. I look back in hindsight and thing it should would have been nice if plugins declared a supported version of WP that actually meant something. WP version numbering is meaningless, and not in a good way.

Which also wouldn't be as big of a problem it is if WP hadn't pushed all plugins to use core versions of everything, without any good way of knowing which version of things core was actually using.

I'd love to see WP deprecate MORE, and remove MORE old code, but reliable communication of that through version numbering seems a basic requirement for that.

[eclev91]

Replying to jorbin:

There are breaking changes every release, only they are generally minor and planned out in such a way that the impact is low.

That feels like the whole problem, and one reason I'm frequently interacting with people who are afraid to hit the update button on their site, let alone enable automatic updates of any sort. I'll refer back to my last comment:

SemVer, and an auto-update system that was cognizant of it, would encourage core to collect these changes under the banner of a major (as defined by SemVer) release

And finally, again:

What's standing in the way of adopting SemVer? Sounds like some changes to core update logic and a consensus?

Is this just something I should be bringing to #core from time to time to get eyes on? Would happily help in contributing to changes in core's update logic where needed.