Re: Revision Standards

[ELISHEVA]

I think the most important thing to keep in mind, whatever conventions you choose, is that various build, configuration tools, and packaging systems all have different conventions about the *format* of version numbers.

The actual numbering you choose (1.10 vs 2.0) is a matter of taste and marketing. A few years back Sun got worried that people would think Java was immature so it gave Java 1.5 two version numbers: 1.5 and 5.0. Some people like to reserve odd minor numbers (the X in 1.X) for development versions and even numbers for published versions. This lets one keep new development versions ahead of the last published release and before the next published release. The main thing is that you form an in house policy and stick to it.

One thing to keep in mind is that many automation systems expect that 1.X and 2.0 are binary incompatible - they represent such a large change that code using a 1.X API will need to be rewritten if consumers upgrade to anything 2.X. Also many people (and some automated packaging systems - e.g. Microsoft's MSI) expect that 2.X.1 and 2.X.2 represent bug fixes that add no new features.

As for specific systems and formats:

• cvs doesn't allow dots - if you are using cvs for version control (some people still do) and want to tag things with their version number, you will need to translate all your dots to dashs or hyphens.
• perl - when assigning a value to $VERSION in your perl modules, you should probably reformat version numbers for your $VERSION variable N.NNNNNN, e.g. 1.9.5 becomes 1.009005 - if you don't Perl will think that 1.1 is version 1.100 and 1.10 is version 1.010 - not at all what you want: It messes up anyone who uses a version number in their require statement. Even though 1.10 is a later version Perl will think it is an earlier one an refuse to load it.
• CPAN If you are uploading distribution files to CPAN, there is a convention that N.NNN_NNN is a development release - available for testing by CPAN testers but not for general consumption.

Perhaps others will contribute additional examples.

Internally, we use a perl module that keeps track of which of our tools need which kinds of version number formats and spits out the right format for whatever packaging tool or code file we are creating.

Best, beth