captain's log Dingens - Made in Germany

Version Build Numbers - A vers.exe preview

Thoughts on version build numbers.

This entry was first published on July 13, 2005, 12:10 AM, CET and categorized as Code.

So far, no comments have been added to this entry. You can add your thoughts to the discussion below.

Reading "Whdbey [sic] Beta2 Build Number and the Build Numbering Scheme we use in DevDev [sic]" inspired me to think about build numbers again - mainly because my build numbering was not optimal at all nor was I happy with it. Identifying the build date from the build number is a nice touch but the developer division's format has one drawback: build numbers are 16 bit only, so the last possible value is 61231 (2006-12-31, 2007-01-01 would become 70101 which exceeds the maximum value of an unsigned short). A more future save format would be to store the date in the build and revision number (e.g. YYMM.DDRR, 506.1400 for the date 2005-06-14, revision 0). But for some reason I did not like that format - maybe because of the lack of separation between date and revision…

The build number scheme

So the problem is to stuff the date (year, month and day) into a single 16 bit value. With this requirement we can encode the year in 7 bits, the month in 4 bits and the day in 5 bits, resulting in the use of the available 16 bits. The resulting build number is constructed as (YY << 8) | (MM << 5) | DD, where YY is the year (0-99), MM the zero based month (0-11) and DD the day of the month (1-31). This is future prove and continuously encoding of the build date. The only drawback is that it is not as easily decodable as the simple DevDiv date concatenation mentioned above. (JavaScript build number en- and decoder)

Tool requirements

Now that I decided on a scheme, I build a command line tool to automate the encoding. While the encoding itself is straight forward to implement the automated update of relevant source files is not, as I want it to work with native resources (VERSION in RC files) and at least for C# and C++/CLI in the .NET world (Assembly.AssemblyVersion attribute in AssemblyInfo.[cs|cpp]). Also, the input files should not be modified. Note to self: The version and win32res switches of al.exe sound interesting for managed targets. A custom MSBuild task could be interesting, too.

Implementation plans

The current idea of operation is to leave the original source files untouched: "compile" the version number - the major and minor version numbers will be extracted from the relevant source files - into an intermediate file and use that one to increase the revision number in successive normal builds. For rebuilds a new build version number is generated from the date. The problem lies in the various file formats: AssemblyInfo.* should be easily handled with some regular expression voodoo, but for RC files care has to be taken about VERSION blocks for multiple codepages - ya, fun of l10n :]

How this will be done is subject to future thoughts - this is a side project and hence on a rather low priority…

…and now for something completely different: "You don't need types, types are for girls."