Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

module version convention

by metaperl (Curate)
on Jun 08, 2008 at 09:35 UTC ( #690906=perlmeditation: print w/replies, xml ) Need Help??

neat version numbering convention seen in tye's excellent Algorithm::Diff
use vars qw( $VERSION @EXPORT_OK ); $VERSION = 1.19_02; # ^ ^^ ^^-- Incremented at will # | \+----- Incremented for non-trivial changes to features # \-------- Incremented for fundamental changes

Replies are listed 'Best First'.
Re: module version convention
by ferreira (Chaplain) on Jun 08, 2008 at 14:47 UTC

    This convention is a bit misleading as it apparently clashes with the convention for CPAN development releases. CPAN development releases are marked by distribution tarballs whose version numbers like '1.19_02' contains underscores. The development releases are meant to publish unstable code which is possibly in-progress work (so they are available to others experiment with that).

    But that only happens if the author defines the $VERSION to be a string, so when it is used (by ExtUtils::MakeMaker or Module::Build) to construct the tarball name, the underscores are there. In the convention you mentioned, the underscore only exists at the source code and disappears after Perl compiles this piece of code (then, 1.19_02 is undistinguishable from 1.1902). They do not generate development releases (as a beginner may think it should) and only creates an artificial three-part version where the last parts are constrained to vary up to 99 (which is enough for most practical uses). So it is not a big deal/win compared to conventions that just use:

    # vv-- Incremented at will $VERSION = 1.1902; # ^ ^^ # | \+----- Incremented for non-trivial changes to features # \-------- Incremented for fundamental changes

    And notice that perl convention itself is to use three rather than two digits as in 5.8.6 = 5.008006.

    NOTE. Development releases have a curse on themselves which is not being indexed by PAUSE, which requires the user to specify a full name at CPAN shell commands like "install AUTHOR/Boo-1.19_02.tar.gz" when installing instead of only "install Boo" (but that is purposeful to avoid development releases to be installed by mistake). The curse is that development releases never get tested as it should and are second-rate citizens at CPAN for many tools.

Re: module version convention
by moritz (Cardinal) on Jun 08, 2008 at 10:19 UTC
    Some developers have the following convention for library version numbers (and a Perl module is a library to me):
    1. Below 1.0 everything is fair game
    2. Above 1.0, all incompatible API changes require a new major version number

    For a module user this is quite comforting, because it means that upgrades within the same major version number will (ideally) never break your application, and if it does, it's a bug.

    For the module author it usually means not to release a 1.0 version until the API is really stable.

    So far I adhere to these standards, but that really doesn't mean anything because none of my humble modules have reached 1.0 yet.

Re: module version convention
by BrowserUk (Pope) on Jun 08, 2008 at 10:09 UTC

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://690906]
Approved by moritz
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2017-12-14 08:42 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (385 votes). Check out past polls.