I've been working on revamping the Windows Marketplace build system for the last month or so. Just yesterday I had to make the decision how we were going to version our binaries. Versioning is a very important of software engineering and it can be very disruptive if you get it wrong. Getting versioning right is also quite often overlooked so I was pleasantly surprised to see two pages dedicated to the topic in the help for our build system. One page talked about the tools used to format and increment the build version and the other page talked about all the different formats.
One of the versioning formats was called "five digit date". That meant if you built today that you would get a build version with a number like "61229". The 6 is for the year 2006, the 12 is for the month of December and the 29 is for today's date. I looked at that and thought, "Well, that's stupid."
You see, versions in executables are historically stored in two DWORDs. The DWORDs are split into WORDs and each WORD represents one of the four parts of a version number. That means that each number in the version cannot exceed 65535.
Using the "five digit date" means that January 1st, 2007 would give you the number "70101". That obviously won't fit into a WORD. The "five digit date" format was an incredibly short sighted engineering decision. Engineering decisions like that drive me crazy.
Amazingly, I glanced over at my email (which has been deathly quiet, so nice) and saw an email from one of the guys that works on the build system. It made me chuckle:
On January 1st, the ‘fivedigitdate’ schema should produce a 70101 version The problem is that value should have a topend in the 65k’s. I don’t know specifically what issues you will see and where you will run into them, but just a heads up that if you are using fivedigitdate you will likely need to let it run as the ‘default’ setting and start running 61232+.
Then last night I was catching up on my blog reading a little bit and I saw the InstallSite blog talking about a "Y2K7 problem". I immediately thought to myself, "No way..." then I clicked on the link in the blog and read the original blog entry from Quan To. This part near the bottom particularly bothered me:
Luckily, we thought of this earlier in the year and changed our build numbers to use XMMDD where X represents the year in development of our product. As long as we ship in 6 years or less, we'll be ok :)
Why is there 6 year a timebomb built into their build process? Why are software engineers cutting these corners? In the long haul, it just doesn't pay off
If you are a software engineer, I encourage you to consider what it means if every line of code you write lasted 20+ years. Make those lines something you'd be proud to show your kids (and maybe even their kids).
posted @ Friday, December 29, 2006 1:34 PM