You are currently browsing the tag archive for the ‘versioning’ tag.

One easy way to get more value out of your build system is to improve one of it’s fundamental outputs: the build number.  Many of us have been using the basic major, minor, revision, increment format for years (I know I did!), but most build systems these days, especailly ones you’ve built yourself, can use any format you like.  A good one that I’ve used in the past is the following:

Template: (Major).(Minor)_(Branch Name)_(Datestamp).(DailyIncrement)

Build Number: 3.4_Prod_20090529.3

Translation: Production Branch, 3.4 release, built on 05/29/09, was the third build of the day.

This provides a wealth of more information than the basic format.  Just from seeing the build number you know when it was built, what major/minor release it is associated with, and what branch it was built out of.  The only piece of information you’re losing versus the old method is the running total number of builds you’ve created since started the project, which is of questionable value anyway.

One issue you may run into if you are using Windows is that it expects the “File Version” value for assemblies to be in the 0,0,0,0 format.   A good way to get around this is to put major, minor, date (with the year removed), and increment in that field and then use the “Product Version” field for your expanded build number.  So, with the example above, you’d end up with a file version of 3.4.529.3 which works great with the file version field.

Advertisement

Author

Jason Lenny is a Lean manager and innovator with over ten years of experience managing production software development pipelines and process.