>>>>> On Tue, 22 May 2007 12:17:41 -0400, John Peacock <[EMAIL PROTECTED]> said:
>> > What's the rationale for treating 1.0 differently from 1.00? I >> mean, we're > talking about version numbers, not dictionaries. >> >> The rationale is that if two version strings are written differently, >> then there must apparently be a version difference that shall be >> visible and not be swept under the carpet. > <ARGGGGHHHHHHH>And you wonder why I wanted the version object code to > return a _normalized_ string, rather than whatever random bits the > author typed that time. </ARGGGGHHHHHHH> My basic attitude on CPAN is that I presume that authors are not typing random bits. If they have uploaded both 1.1 and 1.10 everybody should assume that there is a difference. > I have to side with Julian here, though. As soon as CPAN added > version.pm support, We are talking about CPAN.pm, not CPAN in general. CPAN.pm has not added version.pm support yet. > it should use that exclusively to perform version > comparisons and not string comparisons, for exactly this reason. Two > (or more) different string representations can yield identical version > objects. 1.0 followed by an infinite number of zeros is still > equivalent to 1. An author who added only a trailing zero to a new > file uploaded to PAUSE should not be able to add that "new" release > (short of resetting the "highest VERSION" flag). Under your > (Andreas') scheme, I could release modules that differ only in the > number of trailing zeros... The 1.0 vs 1.000 case (i.o.w. a different positive numbers of trailing zeroes) had no practical relevance on CPAN yet. I'm only referring to the 1.1 vs 1.10 case. Frankly, I don't know how often it had relevance. But I need to stress here that CPAN::Version is pragmatic and had to be so. Whereas version.pm is fundamental in its nature and that's also a good thing. Once version.pm is stable I have absolutely no reason to continue maintaining CPAN::Version. I'm not at all arguing here in favour of CPAN::Version, I'm just answering Julian's questions because it seems that he is interested to hear the whole story. >> Yes, please turn on your time machine and rip the whole v-string mess >> out of perl. Now. Pretty Please. > I tried! I can't even get agreement to deprecated the damn things > (though I've pretty much tamed them as of Perl 5.8.1, since they are > now magic). But, and this is important, as of version-0.72, v-strings > now are converted correctly from Perl v5.6.2 forward (using a > heuristic for Perl < v5.8.1 and magic v-string after that point). And that's a magnificient work. Thanks to it we will hopefully get the expectations of all users about version numbers under one umbrella. -- andreas