Andreas J. Koenig wrote: > Julian Mehnle <[EMAIL PROTECTED]> said: > > For anyone who has similar problems in the future and who reads this > > thread, I'd like to explain the cause of the problem explicitly (as > > I didn't understand it myself due to the various statements in this > > thread being too implicit). > > > > The problem I had is that my META.yml (generated by M::B 0.26) > > had version numbers of the form "2.004000", which is numerically > > correct, but in the new version.pm regime sorts between v2.3999 and > > v2.4001, as opposed to between v2.3.0 and v2.4.1 (as it was > > intended by me). > > You seem to mean "v2.004000", not "2.004000". The latter is a floating > point number, the former a v-string.
I know. But I actually did have "2.004000", not "v2.004000", in META.yml
as generated by M::B 0.26.
> > Whereas old versions of CPAN.pm (<1.8x) perform a numerical
> > comparison only, matching 2.004000 = 2.004,
>
> Sorry, no, this was never the case. CPAN.pm always did a mixed
> string/numeric compare. Specifically "2.004000" was always sorted
> after "2.004" and still is. Both look like floating point numbers so
> they are treated as such. Because they are numerically equal, they are
> compared as strings again with the effect that the longer is sorted
> after the shorter.
I see. Is this documented anywhere?
What's the rationale for treating 1.0 differently from 1.00? I mean, we're
talking about version numbers, not dictionaries.
Anyways, considering what you're saying, why does CPAN.pm 1.7602 treat
2.004000 (from META.yml on CPAN) as being _equal_or_lower_ than the
installed qv('2.004')? (Remember, `r` in older CPANs doesn't complain
about an out-of-date Mail::SPF, whereas in newer CPANs it does!)
> > newer versions of CPAN.pm apply version.pm logic and compare as
> > 2.004000 = v2.4000 >> v2.4 = 2.004, thus always reporting the
> > version of the package on CPAN (whose META.yml is being read) as
> > newer than what's locally installed.
>
> No, CPAN.pm and version.pm were never behaving identically. There have
> always been edge cases, specifically in the treatment of trailing
> zeroes, underline, other non-numeric characters.
Great! Pardon me for saying that, but what a mess! (Not necessarily
yours, though.) "Design by committee" would probably still have been
better than "interoperability by coincidence".
> The above equation does not represent CPAN.pm behaviour. 2.004000 is very
> far away from v2.4000. Every float below 3 is treated smaller than
> v2.1000 because the maximum a floating point number below 3 can reach,
> when converted to a v-string, is 2.999.999.999....
Are you saying that, from CPAN's PoV, v2.1000 > 3? You can't be serious!
At least version.pm doesn't agree (thankfully):
$ perl -Mversion -le 'print(qv("v2.1000") > 3 ? "yes" : "no")'
no
> > The solution is to upgrade M::B to at least 0.2802 (better
> > 0.2805) so META.yml gets generated with correctly formatted version
> > numbers (no erroneous trailing zeros) to fit the version.pm
> > numbering regime.
>
> Upgrading is always a good idea but I hope you do not insist that all
> your users must upgrade everything because not all of them will be in
> a position to do so immediately. Perl has a very good tradition of
> being tolerant it what it expects and conservative in what it emits.
I should have been slightly more explicit. Since, as I tried to explain,
the root cause of my problem was the badly formatted version numbers in my
package's META.yml as distributed on CPAN, it is of course only the
_developer's_ installation of Module::Build that has to be upgraded such
that future uploads of the package will contain a properly formatted
META.yml.
Julian.
pgpWOe9WjxoVE.pgp
Description: PGP signature
