Having carefully avoided ‘release numbers’ in the title of this post, I shall now proceed to describe a release numbering scheme. The specifics of release numbering schemes are endlessly discussed. Each proponent of a specific scheme believing that their scheme is the best. I shall be no different.

One widely accepted scheme consists of period separated integers. The number of integers varies, as does the interpretation of each integer. Again, I shall be no different here and will present a four integer scheme in which each integer has a specific interpretation.

The general form of the release identity presented in this post is as follows.
major.minor.build.patchThis scheme should be broadly familiar to most release managers, especially those dealing with Microsoft assemblies. Whether my interpretation of each integer comports to expectations remains to be seen.

major and minor

The first to components major.minor are the principal release identity. The major component is incremented when functional change is introduced into the release. The minor component is incremented when non-functional change is introduced into the release.

Generally, a functional change modifies the behaviour of a component but the major component of the identity should also be incremented when there is a change to the interface of the component. This provides a simple means of establishing interface compatibility for system components. It is clear, from the release identity alone, that 1.1 of a library is a drop-in replacement for 1.0. Replacing 1.0 of a library with 1.1 should require no changes to the calling application since, by maintaining the major part of the identity the release manager has declared that there are no functional changes and no interface changes between 1.0 and 1.1.

build

It is an inevitable reality of software development that any release will undergo many rounds of testing, each proceeded by a new build of the software to be released. The build component of the release identity. Some people like to left zero fill the build component so that the release identities are sorted into chronological order when sorted using natural ASCII codes. (That is, rather than starting the build component 1, 2, 3, and so on, they start 0001, 0002, 0003.)

patch

A Patch is a partial release. This could mean that only a part of the build is rebuilt, but the entire system is repackaged for release, or it could mean that only one or two components of the entire system are built and released. Either way, the package identified with a patch is considered an incremental package to be applied in patch number order to the underlying release.

For example, suppose we had released 1.0.123 (build 123 of release 1.0) to testing. After this release a minor issue is discovered in a library package. Rather than re-release the entire package again (as 1.0.124) the release manager decides to release the updated library as a patch. This patch is identified as 1.0.123.1 and consists of only the updated library. Subsequently, another library update is required. Again a patch release is chosen and released as 1.0.123.2. In order to release 1.0.123.2 to any subsequent environment must install 1.0.123, then 1.0.123.1 and finally 1.0.123.2 in order to produce the final, correctly configured, system.

It should be self-evident that this patch numbering scheme is only used in unusual circumstances. It should also be self-evident that the inclusion of a patch number immediately alerts deployment engineers of the need to apply patches and the correct deployment sequence.