Process:Versioning Schemes
==========================
:author: Aaron Ball
:email: nullspoon@iohq.net
:revdate: May 08, 2017


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

[width="50%"]
|===
|    X. |     X. |      X
| 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.


[width="50%"]
|===
|    X. |     X. |     X. |      X
| 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)


[role="datelastedit"]
Last edited: {revdate}

// vim: set syntax=asciidoc:
