Why semantic versioning is good for complex plugins, and not WordPress core

WooCommerce has announced that they are skipping from version 2.7 to 3.0 and transitioning to SemVer, or semantic versioning.

SemVer means that each decimal of a release means something. Whereas WordPress 3.9 and 4.0 were identical in importance, but in SemVer, such a change would recognize the difference between a minor feature release and a back-compat breaking major release. I’ll use the same SemVer quote Mike used on the WooCommerce post:

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.

By moving to SemVer, WooCommerce 3.0 will indicate a back-compat breaking major release. The thing is, WooCommerce has historically made changes that broke back-compat, but has a WordPress-like release system. And to be honest, WordPress can get away with it a lot easier than WooCommerce, because WordPress is much more considerate with back-compat.

For complex plugins, breaking compatibility is just a part of life. There are many ways to reduce the burden of breaking changes, but at the end of the day, sometimes changes have to be made. For WordPress core, the line in the sand is quite clear that backward compatibility is paramount and the core team will go to great lengths to create long deprecation windows, with as minimal of impact as possible on users.

I can count more than one release of WooCommerce where backward compatibility was broken quite late in the release cycle, leaving developers of extensions and custom websites scrambling to make sure their past code wouldn’t suddently take down production websites. It’s not a particularly fun place to be. Implementing SemVer will mean more WooCommerce sites don’t upgrade major versions right away, but it will improve reliability.

Extensions will be able to maintain support for major versions, and do version checks, based on the first digit of the release. And they can be confident that minor versions, such as 3.1.x, will be safe for compatibility purposes. This should offer developers and store owners alike more peace of mind.

Why a similar system is bad for WordPress core

If it’s good for WooCommerce and complex plugins, why not core? It’s a good question. But I believe WordPress core is the opposite. Especially thanks to the commitment to back-compat, core should be de-emphasizing versions entirely, instead relying on secure, reliable, frequent updates that can keep more WordPress sites on the latest version, with the least hassle.

If Tesla can do over the air updates to their cars, we can reliably update websites, right? I say that a bit in jest, but only a bit.

Auto updates have been quite successful for minor releases. Certainly, not all sites are on auto-updates; we saw the nasty side of that with the recent defacements of a whole bunch of sites. But the more it is emphasized how important enabling updates is, the less such issues will exist.

What would you say to someone who blocks Google Chrome updates? Or iOS app updates? I’d say, “Why!?” I feel the same about WordPress. It’s different, yes, but with proper systems in place, the vast majority of website owners shouldn’t care about their WordPress version, but rather know it is secure and up to date, and the plugins they use on that site should just work.

WordPress is already functioning on essentially this principle. And it’s in pretty direct contrast to Drupal and other self-hosted content management systems. Just this week, Drupal announced attempts to mimic WordPress’s ease of updates (though didn’t mention WordPress), after a decade plus of infamously painful update procedures.

Drupal has long suffered from major releases that made the burden of upgrade far too difficult, and in Dries Buytaert’s own words, has, “held back Drupal’s momentum.” WordPress’s marketshare, I believe, highly depends on its ease of upgrades.

While WordPress upgrades are far from perfect, they are the best thing out there for self-hosted CMSs. Yet, hosted CMSs still win out on ease of use, because the user doesn’t have to bother at all. WordPress has to compete with that, not with the Drupals of the world.

In short, I believe WordPress itself should be the “no brainer” in the update equation.

If someone is running a complex plugin on top of WordPress, with a lot of custom development or layers of extensions, SemVer makes a lot more sense. Especially for a highly specialized application like eCommerce.

But just because non-semantic versioning is more appropriate for WordPress, doesn’t mean semantic versioning is the wrong call for WooCommerce. And the opposite also holds.

I’m happy to see this change for WooCommerce. In this specific situation, it fits well. But SemVer isn’t one size fits all, in my view.