Today we’ve changed the BuildID from being YYYYMMDDHH to YYYYMMDDHHMMSS.

Extending the BuildID so its not just accurate to the hour, but now accurate to the second might sound like a small simple change, but its quite significant and something we’ve been working on for several months.

Whats the big deal? Why bother put all this effort into something so small? Why is it so important?

First, some background: the BuildID was designed to identify a build to within an hour. Having year/month/day/hour information in YYYYMMDDHH format is perfectly sufficient, so long as we never start more than one build in the same hour. That *used* to be true. In fact when builds normally took over an hour, people could safely assume the BuildID was a unique identifier – after all, it almost always was!

However, in recent years, this became more of a problem because:

• the linux and mac builds take well under an hour, and its easily possible to accidentally create two builds with the same BuildID. This promptly causes weird breakages, and leaves some users unable to update. Win32 builds take much longer, so this problem less likely to happen on win32.
• the AUS updates are sent out to users based on their BuildID. Having two different builds with the same BuildID means that AUS will possibly send you updates for the “other” build. See bug#431866 and bug#432014 for recent examples.
• the Tinderbox, Builds, Unittest, Talos and GraphServer systems all needed ways to uniquely identify builds, so each system invented their own (different!) way of doing this… all because the old BuildID was not good enough. Matching up these different systems – how to post a talos result on tinderbox for example – is quite a headache. We’ve already done some cleanup (here and here), but this new BuildID should let us simplify *much* more of that cross-system integration.
• the graph server is used as a way to track performance, and identify which changes need to be backed out. With the old BuildID, 9.01am looked identical to 9.59am, so the Sheriff had to pad out the entire hour on each side of the regression. Having more accurate ranges reduces the number of changes to consider backing out.

The new BuildID contains year/month/day/hour/minutes/seconds in YYYYMMDDHHMMSS format. We simply added 4 digits to the end. Its the least intrusive change that we could do, and still addresses all the problems above. Hope all that makes sense – of course, please ping me if you have any questions/comments.

Many many thanks to Armen, Bhearsum, Coop, Nthomas and Ted/luser for all their help.

take care
John.

=====

ps: We’ve been working on this for a long while now, in bug#431270. Hopefully, we’ve caught all the edge-cases, but if you see any related weirdness/fallout, please file a bug in mozilla.org:ReleaseEngineering. Thanks 🙂

[update 08aug08: fixed typo in first line, where YYMM should have been YYYYMM. Thanks to Stéphane for catching that. ]