One of the least automated functions in software is the realm of numbering releases. Often, these numbers are functions of a marketing department, trying to impress customers rather than actually following any set standard.
In the movie Tron: Legacy, the character Alan Bradley, a former programmer, now executive, asks the president of ENCOM:
Given the prices we charge to students and schools, what sort of improvements have been made in Flynn... I mean, um, ENCOM OS-12?
And the president replies:
This year we put a "12" on the box.
Ironically, this is not as far from reality as you might expect. But suppose you are responsible for a software release. In that case, you need a version control numbering system that the engineering department can rely on, even if you need to maintain a translation grid somewhere else (hint: You probably will need one).
Version Number Basics
Numbering schemes vary by company but generally follow a template similar to this:
XX.YY.ZZ.AA
Where:
XX is a major release version number
YY is a minor release version number
ZZ is a patch release version number
AA (AAA) is the daily or latestrelease version number
The Daily or Latest release (AA or AAA)
The most automated of the version numbers is the daily or latest stable release number. If you use a build system, the last number is the build number. Every time code builds, the last number increments automatically, whether the build is successful or not. When the build is successful, usually by passing all automated tests, it is considered the latest stable build. This build is usually not released, but teams use it to develop additional features or patches or validate release candidates. While this build usually comes out of the development branch (in a three-branch system), nothing prevents it from coming from other automated build branches.
This number may or may not reset if one of the other three numbers is incremented based on the release management policy.
Many artifact repositories will alias the newest stable build as latest.
The Patch release (ZZ)
The most frequently updated public version number is the patch release number. This indicates changes to the base code that all users should take and update. This may include specific spot releases or roll-up patches from daily releases that are now regression tested and ready for everyone.
The patch release should not include new functionality. This release is a bug fix, major or minor, only.
The Feature Release (YY)
As an application matures, new features are added, and these features do not break backward compatibility but extend existing functionality or introduce new functionality. These releases tend to be less frequent than patch releases.
The Major Release (XX)
When an application does a major release, we discuss new features and functionality that break backward compatibility with prior versions. These big releases might include new kernels, schema designs, or APIs that no longer talk to older versions.
Major versions are often entirely new code bases, redesigned UIs, or tuned to specific hardware or changes to third-party requirements for API interactions. Depending on the software, it is usually possible to run two major versions simultaneously (although you probably do not want to).
Internal versus External Version Numbers
As mentioned, version control can be impacted by marketing. It is common, though bad practice, for the marketing version number not to be updated when a system is patched, even if the internal version number is updated. Sometimes this is to obscure the patch, sometimes, it is to prevent confusion with marketing campaigns and sometimes, it is contractual.
It is vital to ensure that regardless of the marketing number, you keep tight control of the internal numbers, incrementing them per build, patch or feature merge, and, finally, major releases. These numbers should result in tagging in the version control system, and all software that ends up in the artifact repository should be clearly identified.