Versioning for a reason

Please do not push an un-versioned release to your test environment only to recompile and push a versioned dll to your Production environment. If the version numbers do not match then you should not presume that the application code will behave in the same way. If your QA and Testers have signed off version 0.0.0.0 of the application (which could be absolutely anything) How can your product manager confidently allow version 1.0.0.0 or 1.3.11.2 to be released.

So we know that version numbers important, but for whom?

Software version numbers are there for the management of the software through all of the processes that follow the code being written. We need to know what code is being tested, we need to know what code the user has signed off, and we need to know what features are being delivered to the end user. The only person that doesn't need to know about the version number is the user themselves.

How do we keep our version number unique?

The version number of a .Net assembly is made up of 4 sets of numbers (Primary, Secondary, Tertiary and Quaternary). We *could* just use four sets of random numbers, alternatively we could make this version number into something more meaningful.


We could use the Primary number to represent the primary functionality offered by the product. When there is a significant upgrade to the functionality, perhaps the number could increment based in the completion of an epic story. Given this, the product manager is able to understand what his product is offering based on this number.

We could use the Secondary number to represent incremental updates to the existing functionality. These would be enhancements to existing functions of the system, perhaps indicating project milestones or story completion.

We could use the Tertiary and Quaternary numbers as an incrementing 'unique' aspect to the full version number. I have previously used these to signify the time from the start of a Product's development. Currently I am using the Tertiary number to represent the days since development began and the Quaternary number to state the build number for that given day.

What have we got?

We've now got a version number that is not just unique, and therefore traceable through all stages of our development and deployment processes. But one that also contains meaning for everyone involved in the process of delivering the software to the end user.