File Versioning

< Day Day Up >

File Versioning Every file in a product should have a version number; a four-part number separated by periods such as the one that follows seems to be the established best practice. There are many variations of what each part represents. I will explain what I think is the best way of defining these parts. <major version>.<minor version>.<build number>.<revision> Major version� The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release. Minor version� The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release. Build number� The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code. Revision� The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release. Note These numbers range between 0 and 64K and can be enforced by a prebuild test tool or a build verification test. As a rule of thumb, each codeline in a source tree should have its own build number, and that number should start at zero when the branch is created. If it is a build off of the main trunk, the build number should go into the <revision> field. Keep your mainline incrementing with each build as long as it is still the tip of your source tree. See Chapter 16, "Managing Hotfixes and Service Packs," for detailed examples on this labeling. For example, 5.1.2600.2180 is a typical file version for a Windows XP SP2 binary. Let's break this down in more detail: 5.1 is the major and minor internal version number of Windows XP that is always used in our bug tracker. If this was a Windows 2003 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. How can this revision build number (2180) be smaller than the original XP RTM build (2600)? The reason is because the SP2 codeline is a branch off the XP mainline (the 2600 codeline). When the branch was made, the build number was reset to 0. The large number of builds is a result of SP2 containing all the SP1 changes, which was the same branch. (The RTM build number was 1086 for SP1.) If this was a one-off hotfix rather than a service pack release, the <revision> field might have the number of the bug that was being fixed, such as 1000 (if this was the bug number). Again, to better visualize this, see the sample VSS tree drawings in Chapter 16. Warning: Product Marketing Numbers Mixed in Version Strings Are a "Bad Thing." There seems to be a common misuse of product marketing version numbers for the major and minor numbers in the version string. Don't use the product marketing version in the file version string because different products use some of the same components. Furthermore, marketing numbers don't always follow a sequential order, and sometimes they're random. If, on the occasional circumstance, the marketing people want to use the internal version number of a product, such as NT 4.0, for their marketing version, this would be okay. Just don't link the two numbers in a permanent way.

< Day Day Up >