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
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.