2009/4/22 Yitzchak Scott-Thoennes :
> I didn't see any "in META.yml" restriction in David's dicta. And I
> would be very surprised if META.yml publicized a different version than
> I picked.
META.yml is a machine to machine format, theoretically humans aren't
even supposed to be reading it except
On Tue, Apr 21, 2009 at 4:46 PM, Yitzchak Scott-Thoennes
wrote:
> But then, I'm sticking to the rule:
>
> $VERSION SHOULD be a version object.
> $VERSION MUST be a number or version object.
Nice. I think you just compressed 80% of my verbose recommendation to
2 pithy lines. I would add:
# from David Golden
# on Tuesday 21 April 2009 13:34:
>Because perldelta implies that v-strings aren't supposed to be used
>for version numbers. It's pretty explicit for Perl version numbers
>and even has a warning for 'use v5.10'.
v-string in use/require is non-portable
Perl w
David Golden wrote:
>Subject: Re: versions just won't ever be sane *and* compatible
Dotted tuples were a mistake. Plain decimals are sane, and compatible
all the way back.
-zefram
On Tue, April 21, 2009 1:23 pm, Eric Wilhelm wrote:
> # from Yitzchak Scott-Thoennes
> # on Tuesday 21 April 2009 13:02:
>>> I don't "dislike" the underscore. It _does_ _not_ _work_ as a
>>> delimiter in a version number because perl does not treat it as such.
>>
>> Yes, it does, wearing its versi
On Tue, Apr 21, 2009 at 4:34 PM, Eric Wilhelm
wrote:
> $ perl5.8.8 -e 'BEGIN{package foo; $VERSION=v0.2.1_1;
> $INC{"foo.pm"}=1;} use foo v0.2.10; print "yipeee!\n"'
> yipeee!
>
> $ perlv5.10.0 -e 'BEGIN{package foo; $VERSION=v0.2.1_1;
> $INC{"foo.pm"}=1;} use foo v0.2.10; print "yipeee!\
On Tue, Apr 21, 2009 at 4:23 PM, Eric Wilhelm
wrote:
> Can anyone give a reason for use() to treat version.pm objects and
> v-strings differently?
Because perldelta implies that v-strings aren't supposed to be used
for version numbers. It's pretty explicit for Perl version numbers
and even has a
# from Eric Wilhelm
# on Tuesday 21 April 2009 13:23:
>No, it is not ok to get success from 'use foo v1.2.10' when foo's
>$VERSION is v1.2.3_1 -- especially when a version.pm comparison would
>tell you that v1.2.10 > v1.2.3_1.
Oh, whatever. I give up.
$ perl5.8.8 -e 'BEGIN{package foo; $VERSI
# from Yitzchak Scott-Thoennes
# on Tuesday 21 April 2009 13:02:
>> I don't "dislike" the underscore. It _does_ _not_ _work_ as a
>> delimiter in a version number because perl does not treat it as
>> such.
>
>Yes, it does, wearing its version object (aka version.pm) hat.
>
>perl does not treat vs
On Tue, April 21, 2009 11:51 am, Eric Wilhelm wrote:
> # from David Golden
> # on Tuesday 21 April 2009 11:19:
>> Leading "v" AND two separators (period or the hated underscore).
>
> I don't "dislike" the underscore. It _does_ _not_ _work_ as a delimiter
> in a version number because perl does not
On Mon, April 20, 2009 10:55 pm, Eric Wilhelm wrote:
> # from Yitzchak Scott-Thoennes
> # on Monday 20 April 2009 18:53:
>>> Form (a) is recommended for all new version numbers. Form (b) is
>>> allowed for compatibility with legacy version numbering.
>>
>> Use a triple tuple if you like, but I wan
# from David Golden
# on Tuesday 21 April 2009 11:19:
>Leading "v" AND two separators (period or the hated underscore).
I don't "dislike" the underscore. It _does_ _not_ _work_ as a delimiter
in a version number because perl does not treat it as such.
And, since perl 5.10.0 cannot be fixed, ve
On Tue, Apr 21, 2009 at 2:07 PM, Adam Kennedy
wrote:
> We don't need to pussyfoot around with any of this "what if the v
> accidentally falls off the number because a while loop was rotating
> too fast".
normal() today puts a "v" on. Apparently that isn't Test::YAML::Meta
friendly (yet) and "v"
2009/4/22 David Golden :
> On Tue, Apr 21, 2009 at 1:49 PM, Adam Kennedy
> wrote:
>> 2009/4/21 David Golden :
>>> Any version that does not appear in the form of type (a) or type (b)
>>> is considered invalid. The behavior of modules encountering invalid
>>> versions is undefined.
>>
>> Well that
On Tue, Apr 21, 2009 at 2:01 PM, Adam Kennedy
wrote:
> It's a file format spec. Go strict or go home.
+1
2009/4/21 David Golden :
> I'm not worried about enforcement just yet. I see this is a
> recommended convention -- to be followed by aggressive communication
> if there's a consensus.
For META.yml, I'm not the least bit interesting in recommendations of any kind.
Agree on a design, whoever think
On Tue, Apr 21, 2009 at 1:49 PM, Adam Kennedy
wrote:
> 2009/4/21 David Golden :
>> Any version that does not appear in the form of type (a) or type (b)
>> is considered invalid. The behavior of modules encountering invalid
>> versions is undefined.
>
> Well that's not particularly helpful.
I don
2009/4/21 David Golden :
> Any version that does not appear in the form of type (a) or type (b)
> is considered invalid. The behavior of modules encountering invalid
> versions is undefined.
Well that's not particularly helpful.
Also, why exclude v1.23 useful as a tuple...?
Adam K
da...@hyperbolic.net (David Golden) writes:
>> This would be OK except that the original bug report was Debian's
>> packaging tool being unable/unwilling to cope with version's with
>> leading 'v' (which we can actually claim is Debian's problem).
>
> As long as we can give them something unambigu
# from John Peacock
# on Tuesday 21 April 2009 03:35:
>You aren't using version.pm comparisons in both cases, so it shouldn't
> be all that surprising that it doesn't work the way you'd expect it.
I think you need to treat it as a version.pm bug. The comparisons don't
match perl's.
$ perl -e
Eric Wilhelm wrote:
> I'm very troubled by any inclusion of underscores in the META.yml spec
> because they behave differently between perl v-strings and version.pm.
>
> Example: v1.0.2_3 gt v1.0.3, but qv(v1.0.2_3) < v1.0.3
You aren't using version.pm comparisons in both cases, so it shouldn't
21 matches
Mail list logo
