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
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
>
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
> 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
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
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
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
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
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.
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
# 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
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
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
# 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
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
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
16 matches
Mail list logo