Should There Be Other Fields in the File Version Number?


I am of the opinion that no, there shouldn't be other fields in the file version number. Let's look at some other fields that might seem like they should be included but really don't need to be:

  • Virtual Build Lab (VBL) or offsite development group number You can use this number to track a check-in back to a specific site or lab that the code was worked on. If you have a golden tree or mainline setup, and all your VBLs or offsite trees have to reverse integrate into the golden tree (as discussed in Chapter 2), this extra field would be overkill. That's because you can trace the owner through the golden tree check-in. Having a field in which you would have to look up the VBL or offsite number would take just as long.

    The reality is that when you check a version number, you won't care where the file came from. You'll only care if it is a unique enough number to accurately trace the file to the source that created it. Most likely, you'll already know the version number you're looking for and you'll just need to confirm that you're using it.

  • Component If you break your whole project into separate components, should each component have its own identification number that would be included in the version string? No, similarly to the reasons in the previous bullet, you can track this information by the name of the binary or other information when checking the other properties of the file. This information would probably only come into play if you were filing a bug and you had other resources available to determine which component this file belonged to.

  • Service Pack Build Number If you're doing daily builds of a service pack release, you should use the earlier example; increment the build number and keep the revision number at the current in-place file build number. This seems like a good argument for a fifth field, but it isn't if the revision field is used properly.

There might be one exception to adding a fifth field that falls under the external releases of your product: You might want to add the word .BETA at the end version string so that people will know at a quick glance that they are running beta code upon checking the version. Some testers argue that this extra field, which would be truncated on the final release, changes the byte count of the binaries, which then would affect the testing. This is probably true, so you have to weigh the consequences.



The Build Master(c) Microsoft's Software Configuration Management Best Practices
The Build Master: Microsofts Software Configuration Management Best Practices
ISBN: 0321332059
EAN: 2147483647
Year: 2006
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net