Properties of version numbers

A software product is usually identified with a name and a version number.

The most fundamental requirement is for the version number to be unique, or it will fail to identify the product. The easiest way to achieve this is to assign the next available positive natural number to a new version.

1, 2, 3, ...

Besides being unique, the version number is also used to communicate various properties of the product. The most common are

* Compatibility with other versions
* Promise of support
* Interface stability
* Quality
* Market expectations

If a commitment is made to support old versions with bug fixes, we need a way to branch the version number, because the next natural number may already be taken when the need for a bug fix arrives. The convention is to use a point to start a branch.

2 => 2.1, 2.2, 2.3, ...

This simple branch pattern has one major drawback. It is not possible to create more than one branch from each version. This can be overcome by inserting a branch name.

2 => 2.bf.1, 2.bf.2, 2.bf.3, ...
2 => 2.customerX_special.1, 2.customerX_special.2,...

You may recognize this naming pattern from ClearCase, which also follows the convention that the zero version in every new branch is identical to the parent, e.g. version 2, 2.bf.0, and 2.customerX_special.0 are all identical.

By assigning special meaning to branches, we can also communicate promises about compatibility and stability of interfaces. For example, a .stable.* branch could only contain modifications that don't change public interfaces. A .bugfix.* branch could also keep the target environment intact, to guarantee drop in compatibility.

Note that a version number is chosen by looking at the relations the new product version has with earlier versions. We do not make any special considerations about which number to assign to any future version of the product. The freedom to assign future version numbers is secured by an open numbering scheme.

Many developers also insist on encoding the quality of the product in the version number. This is a bad idea for several reasons. The quality of the product is established through tests and extended use. This necessarily comes after the fixation of the product gestalt and identity, which includes the version number. Therefore, it is impossible to know anything about the product quality at the time of manufacture, when the version number is assigned. Consider this. After much hesitation, the developer decides to put the stamp of approval on an untested product anyway, by giving it a version number which communicates high quality. All is fine until the first serious bug is found, requiring a bug fix release. Now we have a product version with an identity indicating high quality, which it obviously doesn't have.

Quality based numbering schemes also has a tendency to close the available name space for versions that are actually built and delivered, by assigning numbers to future versions ahead of time, versions which may never actually be produced.

The sound way to communicate the quality of a specific product version is via statements made about the product in reviews, test protocols and bug track records.

Marketing considerations can also put pressure on developers to assign version numbers which do not conform to established technical standards. The solution is to treat any numbers coming from marketing as part of the product name, e.g. Webspunk 7.0 (version 257.bf.17).

More information about version numbers.