Just a few notes I’ve gathered on software/application versioning [standards]:
A full version number (eg: 1.4.3.9) is made of four parts: [major].[minor].[revision].[build]
Major number is incremented only if there is a major milestone in the life cycle of the object under version control such as for each successive release. Minor number is incremented for smaller but still significant modifications, new features or bug fixes. Sub (-sub) version numbers or revisions may also be used, if required, for minor changes or (typically non-critical) bug fixes. It all depends on the garanularity of the change manifest. A build number is generally a system-generated source control commit or compilation number in increments.
Version number for a specific product can also convey some information about the product. For example, all Linux kernels with ‘odd’ version numbers (eg: 2.3) are experimental, so you would not find a kernel from 2.5 family in a production system. Hence, the *nix numbering scheme is that ‘even’ version numbers are stable releases while ‘odd’ versions are releases with new features that are not yet sufficiently tested.
On another aspect, take for example, version 9.72. This is pronounced as version nine point seventy two. That is, there had been 72 mini-releases since we got to release 9. Its important to realize that version 9.70 is not the same as version 9.7, while in this case, 9.7 is the same as 9.07.
VB6 Versioning Tip: Visual Basic (6.0) inexplicably omits one of the fields in your application’s version number resource. The version number standard is as follows: Major.Minor.Revision.Build. What VB normally gives you is this: Major.Minor.0.Build. In other words, the Revision field is always set to 0. To confuse matters further, what VB calls the Revision field is actually the Build field. Its also interesting to note that the core Windows system uses 4 part version system (eg: 1.4.7.2) while VB6 uses a 3 part version system (eg: 1.4.7).
Version numbers may also include an additional text predicate like Alpha, Beta, RC etc. An ‘alpha’ release is generally the first viable version to be released to a very small number of users/testers. A ‘beta’ release is rolled out after an initial round of ‘alpha’ testing, by which time the developers have worked out most (if not all) of the initial bugs and problems. It usually involves a significantly large tester/user base, but is still seen as a test release. A ‘RC’ or Release Candidate is ususlly the final ‘beta’ release, whereby the vast majority of known bugs have been resolved, and the product is considered quite close to the final version, but it is still possible that a few major bugs may still be encountered. What ultimately follows is a final release, also know as the Golden or Super Furry release.
Apple’s Version NumberScheme is also a good reference point for developing a custom version scheme.
CVS, or the Concurrent Versions System, is an open standard for version control that allows for a robust version control system to be in place to insure control over changes to an application as it is being designed and developed, during testing and QA and post-production during content management and improvements. I highly recomment TortoiseCVS (open source) on this front.