You may also want to look at Seeking thoughts on version numbers in modules. I personally don't think version.pm and 3 part version strings are ready for prime time quite yet.

This might serve as a reminder not to use three part version numbers for your CPAN modules.

It should actually act as a reminder that I need to remember to watch out for these threads, so that things don't deteriorate to this point. :(

What TheDamian is suggesting in Perl Best Practices is to use a structured version object, via the version module. All version comparisons DTRT and there aren't any suprises like can be caused with v-strings. As an aside, I was as thunderstruck as anyone to see this recommendation when he made it during his Best Practices Perl talk in 2004. I wasn't convinced that version.pm was ready for prime time yet. I was even more stunned to discover this past summer that Module-Starter-PBP already contained the recommended

stanza. I alerted Andreas to this fact and went back to check in some changes to version.pm based on his tests.

Contrary to what is said in this thread (and in fact in the 0.50 version.POD), Andreas has updated the CPAN indexer to correctly parse version objects and add the value to the index files as a number. That distinction is important since both CPAN and CPANPLUS expect the $VERSION column in the index file to be a floating point number (the old style $VERSION). The version.pm module contains logic to convert between a floating point and a multi-dot version object in an internally consistant manner.

Your problem is that you didn't read the version POD (or you did and my poor documentation skills prevented you from understanding) and tried to mix Numeric Versions with Extended Versions (to use the terminology I've recently adopted). The problem is that your existing CPAN release was done like this:

But that is equivalent to an Extended Version of 0.10.0! Strange but true! The conversion code breaks floating point number implicitely on 3 decimal place boundaries, adding zeros on the right as needed to make up a clean multiple of 3. This is required by the fact that Perl 5.6.0 was equivalent to 5.006.

When you added a new release to CPAN like this:

the PAUSE indexer correctly noted that this was less than the current CPAN release (remember, equivalent to 0.10.0), and hence, although it was correctly added to your CPAN directory, it will not show up in the index because it isn't "newer" than the older release.

The correct fix is to submit a new release to CPAN like this:

or whatever suitable increment you see fit, such that it is a higher version than 0.10.0.

There, clear as mud???

More accurately, this would be a warning not to mix two-part and three-part version numbers. version works fine if you use three-part version numbers exclusively.

I have to say that using v-string-like version "numbers" is wishful thinking not a "best practice". It might be a best practice in another few years. Right now, it is just asking for problems, many of which will be problems not for you but for the people who try to use your module and thus are the types of problems that it is even more important to avoid.

My suggestion to you is to upload version 0.0101 or 0.0104 or 0.0204 or 0.02004 or such of your module. Treating the purpose of the segments of your chosen version "number" too strictly is a mistake. You appear to be quite reluctant to increment the middle part of your version number; please don't be. What is important about version "numbers":

• The sort order is obvious to both people and to programs
• Two different versions must have different version numbers
• Version numbers "increase"

Other considerations should be treated gingerly. I've seen tons of examples of people trying to assign meaning to certain aspects of version numbers that result in problems. For example, there is a CPAN module that tried to make the integer part of the version number match the release year. A minor "oops" followed by a too-hasty (IMHO) correction means that this module is now version 9999.xxx.

I've previous written versions as:

use vars qw( $VERSION );
$VERSION= 1.01_03;
[download]

But I worry that the "_" being there in the Perl source code but not there when you do:

print $My::Module::VERSION
[download]

could be a source for confusion that I can avoid (note that I don't consider using "our" to be a best practice either).

Version numbers like "1.2.3" are harder for computers to sort and are less clear how to handle in Perl. The advantages of "1.2.3" over 1.02003 are quite minor, as far as I can tell. So I much prefer version numbers be used that are trivial for both computers and people to sort and that are obviously just numbers (but sort correctly as strings as well) and so how to deal with them is obvious as well.

(No, I have not yet had a module make it to version 10.xxx. I doubt I'll have this "problem" to address. Though, if I do, I might jump from 4.x to 500.x then from 699.x to 7000.x, etc. and just rename the module if I get close to version 999999.xx :)

Update: I forgot to mention to avoid trailing 0s on the latter parts of your version numbers. So if you go with x.yyzzz, then avoid (skip over) version numbers like 1.00012, 1.01010, 1.10020.

Here's what I got from the PAUSE indexer report. A status of "Falling revision number". The Indexer was somehow converting "0.0.3" to "0.000003", and that being less than "0.01", hence the error.

I suggest you keep 0.01 in your CPAN dir, and name your new release "0.1.3", or "0.2.3", and count from there.

I think that most people will consider "0.01" to be a newer release than "0.0.3". "0.01" reads as major release 0, minor release 1. "0.0.3" reads as major release 0, minor release 0, patch level 3. I don't think you should interpret Damian's suggestion to use three part version numbers as an invitation to just take your two part version number and insert an extra dot. I would consider "0.01" and "0.1.0" to be equivalent, and hence, "0.0.3" to be an older release.

Thanks for the insight.


--
Rohan

> While I think that converting "0.0.3" to "0.000003"
> isn't the correct way

It's the official way. Please read perldoc version.

> it thinks that "0.2" is a newer version than "0.11",
> because it considers "0.2" to be a short hand for "0.002"
> and "0.11"

Wrong. It considers 0.2 > 0.11 because perl does:

% perl -le 'print 0.2 > 0.11 ? "T" : "F"'
T

> most people will consider "0.01" to be a newer release
> than "0.0.3".

Thank you! I couldn't agree more!

> I would consider "0.01" and "0.1.0" to be equivalent

Sorry, the factor 1000 has been chosen to be the perl mapping for each dot in the version string.

> I suggest you keep 0.01 in your CPAN dir, and name your
> new release "0.1.3", or "0.2.3"

Sorry, it would have to be at least a little bit more than 0.10.0, because 0.10.0 is the equivalent of 0.010000 and as such is exactly numerically equal to 0.01.

Dear Rohan

My simple and not quite finished module got in OK yesterday: Catalyst::Plugin::Email::Page

I used module::starter::PBP to create it.

Although castaway made me change it today to Catalyst-Plugin-Email-Page-0.2 and now I use our $VERSION = '0.2';

Here's what I got from the PAUSE indexer report. A status of "Falling revision number". The Indexer was somehow converting "0.0.3" to "0.000003", and that being less than "0.01", hence the error.

Code?

Take a look at things like Class::Std do it.

In Problem with CPAN and module version numbers, TheDamian mentions that the PAUSE indexer does not handle the version module correctly, so I'm not sure if its changed now. The VERSION variable in my module was set as

our $VERSION = "0.0.3";
[download]


--
Rohan

our $VERSION = "0.0.3";

If you're following TheDamian's advice you'll want to use the version module instead of a plain string. Something like:

use version; our $VERSION = qv( '0.0.0' );
[download]

and adding version to your modules prerequisites. NOTE: it's important to keep the use version on the same line since many modules grep out the line with $VERSION and eval it to get the version number out.

I don't know what TheDamian is recommending, but you might find Re: Versioning modules in a package worth a read.

My viewpoint is that version 'numbers' are not really numbers at all; they are strings that may or may not look like numbers. This is not a computer science statement but a philosophical one. A version number is more like a model name. Does 'Windows 7' sort higher than both 'Windows 98' and 'Windows 2000'? (I know, this is a cheap shot and yes, I know better. Does 'NT 3.5' sort higher than '3.11'?)

It's an error to think of any version number format as pure, correct, or a real number. To be precise, the set of version numbers (for any project) do not constitute a field or even a ring. We should all be grateful that Perl Hackers aren't trying to release modules with versions like 'Cougar' and 'SX-2010'.

That said, it's good to play nice with others sometimes. This is one of those times. I don't endorse novel version numbering schemes. Use an accepted format. Understand how various formats are incremented.

Everyone agrees that mixing version number formats is Bad News. I say, once you pick a format, that's it -- you're stuck with that format forever, for the life of the module. Comparing 0.2.0 to 0.12.0 is funky enough without trying to compare either to 0.010002 let alone... well.

Docs for version say clearly: "You are strongly urged to set 0.77 as a minimum in your code..."

Combining this with Conway's recommendations yields:

use version 0.77; our $VERSION = qv('1.2.3');
[download]