Romance and Rebellion in Software Versioning

September 26, 2015

How software versions should be numbered

Dominic Tarr's "Sentimental Versioning" is like an advanced class in software versioning. It appears to encourage developers to break the rules, but, really, only if they can come up with a better scheme. Or at least one more entertaining.

The software industry has more or less settled on the semver convention of how to number new versions of applications, shared library packages, and APIs.

As currently stewarded by Tom Preston-Werner, semver, or the Semantic Versioning specification (2.0!), dictates that the numerical format for numbering of your software releases should go like this: X.Y.Z, or major_release.minor_release.patch.

Generally speaking, version 1.0 of a program or API should be ready for production duty. The devs won't go and change around the APIs and break all your connections: All subsequent releases in the 1.0 family, which are minor releases, should be backward compatible with 1.0.0 itself. Only the next major version, a version 2.0, might have features and functionality that could break compatibility from the 1.0 interface.

And a bug fix, a 1.1.1, should be pretty much invisible to end users--Other than that it may make something work that didn't work before, natch.

The current version of Linux for instance is 4.2.1.

(Though, it should be pointed out, that Linus doesn't exactly follow this convention blindly. Linux jumped from 3.19 to 4.0 only after an informal poll of kernel developers showed a slight preference for the more seasoned-sounding 4.0, rather calling the next release 3.20. The Linux kernel pretty much always advances in what could be considered minor revisions, albeit ones issued in rapid cadence. A few devs thought going beyond .20 seemed unseemly, somehow. Torvalds' subsequent reasoning was that the 4.0 release marked the point at which the kernel codebase surpassed 4 million Git objects, up from 2 million in the 3.0 release.)

A numerically rigorous method of versioning software is more than just keeping things tidy, Preston-Werner pointed out in his documentation. It is a way to keep users from descending into dependency hell, where updating a system can prove to be nearly impossible to due to overly exacting requirements requiring specific versions of shared packages.

While everyone probably agrees a consistent numbering scheme is a Good Thing, there are those software managers who flout convention, either out of ignorance or of a willful disregard. This is the focus of "Sentimental Versioning" where Tarr seems to both hold in awe and yet at the same time subtly mock a few software packages' oddly variant versioning schemes.

"Draw inspiration from the way their version numbers express intangible aspects of the project, and are a work of art on their own," Tarr advises, maybe in jest, maybe not.

How software versions should be numbered Tarr highlights three software projects. One is Node.js. Although widely in production use at the time of Tarr's writing, Node was at version 0.12, which in versioning years, made it barely a baby beta. It has since jumped, rather jarringly, from 0.99 to version 4.0. Version 4.1.1 is the current version. Cray!

"Node.js is like a rebellious teenager. It skips class and plays in a punk rock band - yet still gets straight A's," Tarr writes. "Version numbers alternate between even and odd, and between stable and unstable."

Then there's the Backbone.js framework with what its maintainers call a "romantic" numbering scheme, a neccesary one, they say, given that if the strict semantic numbering protocol were followed, Backbone would be up to, like, version 43.0.0 by now (Current version is 1.2.3, Har!). As a result, Backbone users expect that even minor updates can break comptability.

The most egregious violator, and yet also the most poetic, is Donald Knuth's TeX text layout system. Knuth simply uses Pi digits to enumerate the successive versions of TeX (Current version of the 37 year-old typesetting system is 3.14159265).

"It has been prophesied that the last change not be made until after the day Donald ascends to heaven on a shining cloud. At that point, Donald will make one last ssh connection down from heaven to his server at Stanford University and set the version number unto p exactly," Tarr writes.

I mean, would you pick an issue with Knuth? But the deeper truth that Tarr argues is that if you are going to break routine, do it with panache.