Re: Analysis of version number formats in the wild

2009-04-23 Thread David Golden
On Thu, Apr 23, 2009 at 10:52 PM, Adam Kennedy wrote: > 2009/4/24 John M. Gamble : >> 2) CPAN packages are named using that number in META.yml. See above. > > Can someone remind me why the package naming matters again? So a tarball name has some external meaning that doesn't require opening it up

Re: Analysis of version number formats in the wild

2009-04-23 Thread Adam Kennedy
I think it's worth noting that in David's results, a total of only 4 modules on the whole CPAN have tuple elements higher than 999. Adam K 2009/4/23 David Golden : > On Thu, Apr 23, 2009 at 4:18 AM, Adam Kennedy > wrote: >> A more interesting question then becomes, does anyone on the CPAN have >

Re: Analysis of version number formats in the wild

2009-04-23 Thread Adam Kennedy
2009/4/24 John M. Gamble : > 2) CPAN packages are named using that number in META.yml. See above. Can someone remind me why the package naming matters again? > To me, an X.YY version > number goes to X.YY.00, and that's how I've been numbering them. I think the "obvious" requires that you have d

Re: Analysis of version number formats in the wild

2009-04-23 Thread Andreas J. Koenig
> On Thu, 23 Apr 2009 15:57:11 -0500, "John M. Gamble" > said: >> This is guaranteed to confuse authors: "I had $VERSION = 1.002 and >> the package is named foo-v1.2.3.tar.gz!!! WTF???". The _only_ time >> any given module has a potential for confusion is the discontinuity >> betwee

Re: Analysis of version number formats in the wild

2009-04-23 Thread John M. Gamble
John Peacock wrote: John M. Gamble wrote: 1) there is one, and only one, format for a version number in META.yml. This way we have a mechanism that won't make the non-perl world cry. It's a little too late for that; there are already 2 different Perl versioning schemes actively used in META.y

Re: Analysis of version number formats in the wild

2009-04-23 Thread John Peacock
John M. Gamble wrote: 1) there is one, and only one, format for a version number in META.yml. This way we have a mechanism that won't make the non-perl world cry. It's a little too late for that; there are already 2 different Perl versioning schemes actively used in META.yml's on CPAN (well, m

Re: Analysis of version number formats in the wild

2009-04-23 Thread John M. Gamble
John Peacock wrote: David Golden wrote: On Thu, Apr 23, 2009 at 4:18 AM, Adam Kennedy wrote: A more interesting question then becomes, does anyone on the CPAN have a tuple with an element higher than 999. I did another run with zeros vs 1-9, too: http://echo.dagolden.com/~xdg/f

Re: Analysis of version number formats in the wild

2009-04-23 Thread John Peacock
David Golden wrote: > On Thu, Apr 23, 2009 at 4:18 AM, Adam Kennedy > wrote: >> A more interesting question then becomes, does anyone on the CPAN have >> a tuple with an element higher than 999. > > I did another run with zeros vs 1-9, too: > http://echo.dagolden.com/~xdg/format-analysis-zeros.tx

Re: Analysis of version number formats in the wild

2009-04-23 Thread David Golden
On Thu, Apr 23, 2009 at 4:18 AM, Adam Kennedy wrote: > A more interesting question then becomes, does anyone on the CPAN have > a tuple with an element higher than 999. I did another run with zeros vs 1-9, too: http://echo.dagolden.com/~xdg/format-analysis-zeros.txt There are some, but now many.

Re: Analysis of version number formats in the wild

2009-04-23 Thread Adam Kennedy
2009/4/23 Eric Wilhelm : > 1.0101 is 1.10.100.  But, the point: you can't reliably convert tuples > to numbers if any part is over 999, so you have to convert the float to > a tuple to compare with a tuple. Any excellent summary of the core problem. A more interesting question then becomes, does

Re: Analysis of version number formats in the wild

2009-04-22 Thread Eric Wilhelm
# from Adam Kennedy # on Wednesday 22 April 2009 20:33: >2009/4/23 Eric Wilhelm : >> I think this comes at it from the wrong end.  You have to go from >> floats to tuples to compare between them.  So, 1.0101 -> 1.10.1. > >You didn't zero-pad to the nearest triplet. That's actually 1.10.100. Right

Re: Analysis of version number formats in the wild

2009-04-22 Thread Adam Kennedy
2009/4/23 Eric Wilhelm : > I think this comes at it from the wrong end.  You have to go from floats > to tuples to compare between them.  So, 1.0101 -> 1.10.1. You didn't zero-pad to the nearest triplet. That's actually 1.10.100. Adam K

Re: Analysis of version number formats in the wild

2009-04-22 Thread Adam Kennedy
The most common float <---> tuple translation approach (which is the one Perl itself uses) involves the idea of zero-padded triplets. D:\cpan\trunk\Perl-Dist-Strawberry>perl -e "print $]" 5.01 As far as I know, when extended to CPAN versions, the convention has been to pad out decimals to the

Re: Analysis of version number formats in the wild

2009-04-22 Thread Eric Wilhelm
# from Austin Schutz # on Wednesday 22 April 2009 16:42: >1.1.1 -> 1.01.01 > > >This could be directly compared with: 1.0101 I think this comes at it from the wrong end. You have to go from floats to tuples to compare between them. So, 1.0101 -> 1.10.1. >and would solve the case where: 1.9.1

Re: Analysis of version number formats in the wild

2009-04-22 Thread Austin Schutz
It seems like most of the time the XX part is essentially two digits, where the leading 0 is implied, i.e.: 1.1.1 -> 1.01.01 This could be directly compared with: 1.0101 and would solve the case where 1.9.1 > 1.10.1 Looks like the only case where that wouldn't work would be where the format

Analysis of version number formats in the wild

2009-04-22 Thread David Golden
I scanned the version numbers as parsed out of distribution filenames on my minicpan and analyzed the generic format. Since we're talking about distribution version numbers and most of the time those will be generated by M::B, EU::MM or M::I and applied to META.yml and the filename, it's reasonabl