>>>>> 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