Process:Versioning Schemes

I have been on the hunt for a while for a good versioning scheme that’s flexible enough to meet the needs of multiple teams, not be too complex, and also not have enormous numbers right out of the gate (hint hint, like the number 53 - you know who you are).

I really like how the Linux kernel does its general release management, so this is slightly taken from them, as well as Crux Linux package versioning.

That said, versioning schemes are a very opinionated matter, from no versioning, to date built, all the way to just using a build number (which quickly reaches into the thousands if you do CI and CD - a new build and new version per commit effectively).

That said, let’s get to the details.

The Scheme

This versioning scheme has three (well, kind of four) digits. It looks like…

major

minor

hotfix

The first digit, major, is obviously the major version. It should rarely increment unless there is a huge change in the software or you decide your minor version is just too big (how’s that for arbitrary).

The second digit, minor, is the version that should increment for each new release cycle. Depending on how fast your release cycles are, you will reach well into the tens on this on before incrementing the major digit.

The last digit, hotfix, should almost always be 0. Originally this scheme was two digits, but that doesn’t account for a world where not every unit, smoke, and integration test is written (which is most teams I think) and something is missed. It also doesn’t account for managers who can’t tell customers to wait for the next cycle. This digit is for those scenarios when you’ve done a complete release, to production, but need to do a hotfix release. If you ever need to go above 1 or 2 on this digit, you’re probably doing it wrong and should see a couselor about your boundary issues.

The Forth Digit

As mentioned, there is possibly a 4th digit (if you feel the need for it). This digit is not for the software developers, but for the deployment team, so it’s quite optional in most cases I think. This should always be 0, unless the deployment team needs to make changes to the deployment process contained within your package (usually configs and whatnot). Arguably though, if you’re storing deployment configurations next to your application code, you might be doing it wrong (though that’s very subjective).

With that, this is a very optional digit.

major

minor

hotfix

package

The Real World

In application, this should solve all the problems mentioned at the start of the post. Throw on a -rcX to the end and you’ll have a release candidate process (much like the Linux kernel) for your higher level testing environments without needing to change your versioning scheme. You can even create git tags that match!

Writing this post has been quite the release! (sorry - I had to make the pun)

Last edited: May 08, 2017