October 4, 2011 Leave a comment
I have been struggling a bit with version numbers. Normally version numbers are fairly easy: Major.Minor.Build.Revision. So, a release number would be 22.214.171.124 and subsequent patches (aka revisions) of that release would be 126.96.36.199, 188.8.131.52, etc. Unfortunately, there are two forces that are working against this version numbering schema in the software I am currently working on.
First, the industry does not like change. We have thousands of clients and our system is critical to their ability to work with their vendors, process orders or bill customers. Therefore, once it works it works and they never want to change it. Trying to upgrade these customers is a challenge so we have clients on old versions of our software. Therefore, moving from 4.2.x.x to 4.4.x.x or 4.5.x.x seems like a major step for them. We believe they would be more apt to move from 4.2.1.x to 4.2.6.x because the major and minor are the same.
Second, our software is certified for integration with other software based on the major and minor number. If we change our major and minor number, we need to re-certify our software at a cost. Hence, we would rather not update our major and minor number.
Given these forces, we have created a version schema of Major.Minor.SubMinor.BuildNumber. This works fine for a release (e.g. 184.108.40.206), but for a revision on top of a release this breaks down because we are out of placeholders. So, we end up having builds like: 220.127.116.11a or 18.104.22.1681. Both these are ugly. Does anyone have any better ideas?