>>>>> On Wed, 20 Jun 2007 08:06:58 +0000, Julian Mehnle <[EMAIL PROTECTED]>
>>>>> said:
> Now that Mail-SPF v2.005 has been released (with META.yml fixed to read
> "version: v2.005" instead of "version: 2.005000"), I am still having
> trouble with CPAN.pm:
> | cpan[1]> r Mail::SPF
> | CPAN: Storable loaded ok (v2.15)
> | Going to read /home/julian/.cpan/Metadata
> | Database was generated on Tue, 19 Jun 2007 21:08:40 GMT
> |
> | Package namespace installed latest in CPAN file
> | Mail::SPF v2.005 2.005
JMEHNLE/mail-spf/Mail-SPF-v2.005.tar.gz
> | 1 installed module has a version number of 0
> How come CPAN.pm detects the "latest" version (on CPAN) as "2.005" rather
> than "v2.005"? Doesn't CPAN.pm read the META.yml on CPAN to determine the
> version number?
I've tracked it down.
See, this holds for v-strings:
v2.5 == v2.00000005
And this is true in the perl world:
v2.5 == 2.005
So CPAN.pm finds 2.005 from the CPAN index (because that always
prefers floating point representation for maximum backwards
compatibility).
It then sees "v..." in your module and decides to convert 2.005 to
v2.5 in order to be able to compare them as v-strings. While doing so
it fails to normalize your degenerate v-string into v2.5. This is
probably the main bug.
Since the v-strings turn out to be equal it tries once again to
compare ascibetically and finally finds "v2.5" sorting after "v2.0".
I probably have a fix for CPAN.pm which will probably come with the
next release. But given that this will only work in the future, I'd
urge you to rethink my original recommendation to choose a
conservative approach to version strings and defer the use of
v-strings, in particular degenerate v-strings until all the world
(including CPAN.pm) has used version.pm for at least a year or three.
--
andreas
