A Version Labelling Scheme for Software Product Development

Computer software typically has a . separated version number. These numbers have value in helping to understand which version is being used. There is a shared understanding that things go from the most significant part of the version to the least. Having some precision around talking about a version labelling scheme is useful for setting up product lifecycles and communicating the details of a product.

I’ve heard numerous ways of thinking about the build numbers, normally involving terms like major and minor. I’ve never quite been able to keep the terms and distinctions clear in my head, so was pretty excited to recently hear a different approach, which I’ll share below.

Version.Release.Modification.Build

In numbers this will look something like:
3.4.5.1234

The idea is:

Version — a major product version. Customers care and know about versions. Versions are where potential breaking changes might happen.

Release — a major product release. Customers will care about releases. New functionality and bug fixes are introduced in releases.

Modification — a publicly available bugfix modification to the software. Users should be able to safely move between modifications of a product without breaking things. Modifications are focused around fixing problems in software.

Build — the internal build number for the software. A build is useful for the unique identifier of the software by development. The build number will be incremented automatically by the build system. Typically an officially released modification will only have one build number.

Another factor to consider in the system above is that the first two numbers are typically controlled by the Sales and marketing arms of a company, and the last two should be controlled by engineering. In fact if the last two numbers are being done correctly they should be automatically incremented, not being changed apart from automated systems and well defined rules.

For the first sets of numbers, engineering should be able to suggest that new functionality should be increasing at least the release, but it is a sales and marketing decision as to how much of an increase these might get.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>