Versioning Best Practices – When to Change Major, Minor, or Patch Version Numbers

This is something that you are going to have to take a look at from a couple of different angles as you need to take into account user needs as well as the needs of the software and developers.

In general, your customers aren't going to care very much about what the version number of the software is going to be as long as they know they are running something newer (i.e. Product 2012 is newer than Product 2010) and that they know it is up to date if there are patches that can be deployed (i.e. Product 2012, Update 10). As such, from a customer branding stand point I tend to prefer either a named releases (e.g. Windows XP, Windows Vista) followed by a strict sequence number of patches that may be installed by users.

That said though, writing software that checks things that are easy for the user tends to make the code under the hood much harder to write. Thus I tend to prefer the simple Major.Minor version scheme if only because you can do a simple number comparison to check to see something is up to date as in the following:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

To put this in a bit of context though, I generally don't care how big the minor number gets (i.e. 1.1024) which allows the above system to keep running successfully. Generally the revision numbers are only of interest to internal development and I actually haven't even really seen them affect things that much beyond just giving things an additional number to keep track of.

However, the above two schemes really only don't apply to environments where continuous deployment is being used (i.e. Stack Exchange) which is where I tend to prefer some sort of date followed by a revision number as appears to be used on the Stack Exchange sites. The reasoning for this being that versions are going to change too often in the continuous deployment environment and you may have multiple versions of the code going up in the same day which justifies the revision number and the current date is as good as any for breaking things out even more. In theory you could just use the revision number for everything but use of the current date allows you to keep track of major milestones internally that could make things a touch easier to discuss.

I can tell you how I do it at work.

We have a continuous integration server that builds, tests, tags and outputs a versioned package. We only proceed to the next stage if the previous one is %100 successful.

Our version looks like this: <Major Version>.<Minor Version>.<Build Number>

• Every successful build that has no completed bug fix or feature enhancement increments the Build Number.
• Every successful build with a completed bug fix or feature enhancement increments the Minor Version. This is automatically detected by the presence of a commit message using a particular format. This commit message also automatically get's pulled into the projects ChangeLog.
• Every Major Version increment is done by hand when we have non backward compatible changes, rewrites from scratch or other reasons made on a case by case basis.