I was looking into some customisations for the Team Build server today and I happened across a very interesting post in the MSDN Forums that introduces us to the latest potentially civiliation-ending software bug! Yes the dreaded Y2K7 bug. Just before I head out to start stockpiling tinned food and water for my bunker (location not disclosed),  let me share this with you.

On our Team Build server, I want to configure the build to use assign assembly version numbers differently for release and debug builds. My quick search took me to the MSBuild blog which proved to be a great starting point. The post I was after was conveniently named How To: Update Assembly Version Numbers with MSBuild and it cover exactly what I wanted to do. Off I headed to GotDotNet to download the AssemblyInfoTask and it was at this time I decided I liked the Visual Studio convention of major.minor.YYMMDD.build. This seemed to be quite helpful and I always felt the third number was never very useful anyway

It was then that I read the comments on the blog post and read with interest the comment from Steinar Herland. It seems that we (developers) have gone and created another Y2K-like bug. The Visual Studio versioning scheme has a rather nasty problem that will manifest itself at the stroke of midnight on December 31st this year. As Steinar points out…

Major, Minor, Revision are all System.UInt16 types. (IE they are limited to a maximum of 65534)

December 31, 2006 = 61231 (No problems)

January 1, 2007 = 70101 (Oh dear!)

So in light of this, I expect major delays in the release of all software next year as our entire versioning system grinds to a halt and applications fail to build all over the planet.  Here in Australia we will be one of the first civilations to feel to full force of Y2K7 due to our GMT+10 location. Please spread the word now and save us all. LOL