We have all seen version numbers in products, intuitively we understand that the bigger the number the newer the product.  However what  do all the parts of the number actually mean?  This post explains how version numbers work and what each part means.

A typical version number is broken into four parts, separated by a period.  The number thus looks like:

Major.Minor.Revision.Build

Major

The major version number indicates the products launch release.  The first version of a product is typically version 1.  This number however increases every time a new big release is made.  Typically a product team will increase the Major version when there are many changes in the application, these changes could be due to a change in underlying technology, architectures and framework.  Alternatively the product has changed and has many new features requiring the users to purchase an upgrade.

When the major version changes the minor, revision and build are reset to 0.

Minor

The minor version indicates the addition of new features and enhancements to the product, however the changes are too few to warrant a complete change in version.  These enhancements may include nice to have features, features that were too late to be included in the major release.   Small enhancements to solve user navigation and interaction with the system.  This typically give the value-added benefits to users.

Should there be many new changes that effectively change the products positioning, a major version increase should be considered.

When the minor version changes, the revision and build are set to 0.

Revision

Revisions are bug fixes or commonly known as service packs, hot fixes.  Changes to processes and new features are not part of revisions and thus it is solely there to fix errors and bugs.   As bugs are fixed they are cumulated into a service pack and then released with a change in revision.

When the revision changes, the build number is reset to 0.

Build

Each and every time the programmer or automated build process, recompiles the product the build number is increased.  Many larger development shops have automated build processes that run one or a few times daily.  Each time the build process is run, the build number is increased.

Examples

The following examples walk you through a typical version history of a product

• V1.0.0.0 - This typically indicates that the code project was just created and never compiled.
• V1.0.0.4565 - The developers have been working on the project and have built (compiled) the application 4565 times.
• V1.0.1.0 -  The V1.0.0.x build has just gone into production and the developers are starting to work on bugs, i.e. Service Pack 1
• V1.0.1.545 -  The developers have compiled and fixed bugs, the current build is 545.
• V1.0.2.0 -  The V1.0.1 service pack has gone into production and the development team have started working on Service Pack 2.
• V1.1.0.0 -  Additional features have been requested by the users, however this does not warrant a complete change or rewrite in the application.  V1.1 is started and developers start building until release.
• V1.3.2.789 - This indicates the Version 1.2  Service Pack 2 and build 789.
• V2.0.0.0 -  The underlying technologies, development tools or complete overhaul of business processes are required.  This results in a change in the major version number, to version two.