Andreas J. Koenig wrote: > I've tracked it down. Awesome! Thanks for your efforts!
> See, this holds for v-strings: > > v2.5 == v2.00000005 How is that relevant? You mean that CPAN.pm converts "2.005" into "v2.005"? If it does, then that's fine (even if just by accident). > 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. I see. Is this documented on rt.cpan.org? Do you have any objections to me documenting it there, so I can refer others to it? Or perhaps it would be better if you did that, as you probably understand the problem a lot better and can write a brief bug report without missing the point? > 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. Well, I think there's a use for _some_ modules acting as pioneers and exposing the remaining "bugs" in the Perl toolchain. I can live with my users complaining about the issue as long as I know that things will eventually get fixed. Thanks again, Julian.
pgpctsm1ZjlyN.pgp
Description: PGP signature
