vincem's WebLog

versioning part 2 (breaking down a windows file version)

I have had a couple of good questions from my previous blog entry on versioning of which I will address the first one here and the other one in another entry.

1) What should be used for a build number?

Well I think as a rule-of-thumb a codeline in a source tree should have it's own build number and that number should start at zero when the branch is first created. If it is a build off of the main trunk then the build number should go into the <revision> field. You should keep your mainline incrementing with each build as long as it is still the tip of your source tree. I just right-clicked on kernel32.dll on my machine and went to properties, then clicked on the version tab and found 5.1.2600.2180 listed as the file version.

Let’s break this down in more detail –

5.1 is the internal version number of Windows XP which is always used in our bugtracker, if this was a Win 2k3 kernel this number would be 5.2. If it was Longhorn it would be 6.0.

2600 is the RTM(Released To Manufacturing) build number of Windows XP

2180 is the RTM build number of Windows XP SP2 – SO how could this build be earlier than the original XP RTM (2600)?

The reason why XP SP2 has a lower build number is because the SP2 codeline is a branch off of the XP mainline (the 2600 codeline) and when the branch was made the build number was reset to 0. The large number of builds is due to the fact that SP2 contains all of the SP1(I think the RTM  build number was 1086 for SP1 – same branch) changes.

Confused yet? It is if you do not try to visualize what our source trees look like.

This version format is consistent with my previous post of the 4 part file version number.

For the .NET folks, remember, do not confuse or try to use this number for your assembly versions. Keep the two properties separate but make sure each assembly has both an assembly version and a file version when you ‘right-click’ on it. I got a few questions about that.

Furthermore, I do not like to see dates mixed into a version number simply because there are so many date formats out there that it can be difficult to standardize on one. Also, what if you have more than one build on a given date? How do you handle that scenario?

This leads into how to label your source tree. For the short, simple answer, use the file version that is described above. Use more than just a build number for a label. Of course this is very dependent on the source control tool you use but I have seen at several customer sites (and MS) people just using the build number when you get more value using the complete version string. This will really help you when you need to do a ‘one-off’ hotfix or a SP yourself.