Michael -- I appreciate the suggestion, but the spec is done. I did ask for comments on the final draft a week ago.
I'm open to considering it for Version 3 at some future time. But while I understand the desire not to rely on specific implementations like version.pm, that implementation is the same as what Perl itself does. We could say "the semantics of Perl 5.12.0" for version comparison, but for all practical purposes the toolchain is stuck with verison.pm as the external tool we can use for compatibility. I truly wish it were different. I wish version objects had never been added to Perl. But that train has left the station and we all have to make the best of it. -- David On Mon, Apr 19, 2010 at 8:38 AM, Michael G Schwern <schw...@pobox.com> wrote: > http://search.cpan.org/~dagolden/CPAN-Meta-2.101091/lib/CPAN/Meta/Spec.pm#Comparing_Version_Numbers > is an insufficient description about how to compare version numbers. The > spec should not depend on any implementation, in this case version.pm. > > A description of the algorithm of how to compare version numbers is > necessary for a complete spec. There would be four sections: > > 1) Comparing decimal to decimal > 2) Comparing dotted to dotted > 3) Comparing dotted to decimal > 4) Notes about alpha versions > > > Decimal to Decimal > ------------------ > DEFINITION: Decimal versions are compared as normal decimal numbers. > > EXAMPLE: > 1.0 = 1.0 > 1.0 = 1.00 > 1.0 = 1 > 2.0 > 1.0 > 1.9 > 1.10 > > RECOMMENDATION: To avoid confusion, users are encouraged to use a fixed > number of decimal places in their versions such that comparing as numbers > and comparing as dotted pairs works the same. For example, if your first > release is 1.00 then your second should be 1.01. > > > Dotted to Dotted > ---------------- > DEFINITION: Each integer is compared as an integer with its counterpart in > sequence. If any are not equal, the comparison stops. Otherwise if all are > equal the two versions are equal. Any missing integers are treated as 0. > > EXAMPLE: > v1.0.0 = v1.0.0 > v1.0 = v1.0.0 > v1 = v1.0.0 > v1 < v1.1 > v1.02 > v1.1 > v2.1 > v1.9.9 > > NOTE: This appears to jive with version.pm > > RECOMMENDATION: We recommend using at least 3 integers to avoid confusion > with decimal versions. > > > Dotted to Decimal > ----------------- > RECOMMENDATION: To avoid confusion, when changing between dotted and > decimal versions, it is recommend you increment the first integer. 1.09 > should be followed by 2.0.0. > > DEFINITION: > When comparing dotted version numbers with decimal version numbers, the > decimal is first converted to a dotted version. Then they are compared as > dotted versions. > > 1) The decimal part is multiplied by 1000. > 2) The result is treated as the next integer. > 2a) If the result is a decimal, goto 1. > 3) Alpha versions are left alone. > > EXAMPLE: > 1.02 -> v1.20.0 > 1.2 -> v1.200.0 > 1.2001 -> v1.200.100 > 1.02_01 -> v1.20.0_01 > > NOTE: This appears to jive with version.pm > > > Notes about alpha versions > -------------------------- > DEFINITION: > 1) Strip off the alpha version > 2) If they are equal, the alpha version is the lesser. > 2b) If they are both alphas, compare the alpha numbers as integers > 3) If they are not, compare normally. > > EXAMPLE: > 1.00_01 < 1.00 > v1.0.0_01 < v1 > 1.00_00 < 1.00 > 1.01_01 > 1.00 > 1.00_01 = 1.00_01 > 1.00_02 > 1.00_01 > > RECOMMENDATION: To avoid confusion, increment your version number between an > alpha release and stable. That is, 1.2.3_1 should be followed by 1.2.4. > > NOTE: This doesn't appear to jive with version.pm. Here's what it does: > 1.0100 < 1.0101_01 > 1.0101 > 1.0101_00 > 1.0101 < 1.0101_01 > > IMO X.Y_Z should always be < than X.Y. That is, 1.01 > 1.01_05. This reads > 1.01_05 as "the 5th alpha release of 1.01" just like Firefox 3.6.4 beta 1 > will eventually be followed by Firefox 3.6.4. > > > -- > 40. I do not have super-powers. > -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army > http://skippyslist.com/list/ > >
