Best Practices for Versioning Builds
June 29, 2010
Posted by on
Build numbers are always a topic of discussion. Standard convention for a four part build number consists of Major, Minor, Build and Revision numbers. It’s quite common that the build number for internal release to QA varies from the one released on the field. For e.g. the internal release number could be 220.127.116.11 but version number for the final build (often called release build) given to the field would be 18.104.22.168. This shows that many people start with field version when they branch the baseline for a new release, increment the build number for every QA release and increment revision number for every nightly build. An interesting alternative I have come across is to start with previous version build number while branching for new release and then increment it. E.g. while working on 3.5 release start your QA builds with 3.4.xx.xx and increment it till, you the final build with 3.5. Later eases the communication with internal stakeholders.
Coming to numbers themselves Major and Minor numbers are best left for marketing guys / stakeholders. After all somebody is responsible for getting funds for your next release and it’s these guys that would get it. For remaining two numbers, I don’t see a point in why field would be interested in knowing how many QA releases you did or how many nightly builds were done. So, here is your opportunity to do something creative with those 2 numbers. One of the innovations I have come across here is to use the 3rd number to indicate changes in public API’s that field was dependent upon (though by all means you should avoid changing a published API). If this number changes it’s a signal to field developers to rebuild their assemblies. 4th number can be used to indicate the hotfixes that were done to the release. To summarize, when you a release 22.214.171.124 this release modifies the public API’s and it’s the 4th hotfix since version 126.96.36.199 was released.
So, how you deal with your build numbers?