Please explain your build numbering system
Tuesday, February 10 2009
Build numbers are tricky. Just a set of digits, that we all try so hard to make more valuable than 1.0.0.0, which isn’t helpful at all. Our build servers build. That’s all they do is build. Well I guess they also package.
It’s nice to know that the packages are without having to think to hard about it, so here is the build numbering system we came up with. (Notice the dots at EOL).
[Major].
[4 DigitYear].
[Minor][WeekNumber(zero srtart)]
[DayofWeekNumber1=Monday].
[24Hour][Minute(zero start)]
A the final build number of looks like this …
Snippets / Notes / Video / Screen Cast:
Which interprets as …
- Version 1.3
- Built on Tuesday = 02
- During the fourth week = 04
- 2009
- 10:10 AM
With many product builds, building all day long, and so many versions in the wild, I can look at an assembly version number (that match this) from last year, on a product that I may not be familiar with, and immediately know everything I need to know about it’s original and life span. It’s also very easy in my head to know if there is a newer version.
This is all the information we need from the build number, and it’s nice and sortable in the file system.
We prefixed the MMDD with a Minor build number, because when the week is < 10, the 0 is truncated, which breaks the sort.
Do you have another build number idea?
10 comment(s)
The only time this isn't sortable, BTW, is for builds on the same day, before 10AM, because the 01-09 get truncated. It's not tragic because it's obvious, and the 10-23 builds get sorted pretty nicely.
Why not use Major.Minor.yyyyMMdd.HHmmss ?
Won't that be easier to see the full date and time and still be sortable and resolve the 0 before 10am problem?
e.g. 1.3.20090210.092711
I see my folly. So I should substitute H+1 for the first H.
Numbers can't start with 0, the zero is truncated, so in a text sort 2am, sorts greater than 10am.
How is this scheme clearer then having the regular Major.Minor.Revision.Build with an auto incremental build number, and Manual increment of other fields. To find the date of the build, you still have to look at the properties of the file (most people do not think in weeks and days of week when asked for a Date). Our build just adds a comment into the assembly metadata: "Built on 2/7/08 11:43AM on MACHINE_NAME by BUILD_MASTER" Versions are still sortable based on the version number.
@Timur,
The big benefit for us with the build numbers, is that our build server packages up file packs, using the build number. So imagine getting a zip, or msi file with the build number name. This is tremendously helpful when looking at a large file set either from a backup, or our current artifacts folder.
How do you do this? Is this an MSBuild / NAnt task that rewrites the AssemblyInfo.cs file? How do you avoid this change conflicting with source control?
Our build server is a combination of CC.net and FinalBuilder. I forget where it's done, but it's in there somewhere.
This will break as soon as you hit a minor version greater than 6.
Try it...
[assembly: AssemblyVersion("1.2009.70402.1010")]
Error 2 Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.2009.70402.1010' is invalid'
Each individual part of the version number can't be greater than UInt16.Max - 1.
@Justin,
Yup - good call. To date we haven't hit this. Good catch. Thank you. I don't think we'll change it, but it's good to know our failure points. MaxMinor version == 6 :)