On Mon, Apr 20, 2009 at 6:28 PM, John Peacock
<john.peac...@havurah-software.org> wrote:
>> (a) A tuple of at least three integers, prefixed with a leading "v".
>> Tuples may be separated by either periods (".") or underscores ("_").
>> Examples: "v1.2.3", "v3.14.0", "v1.2.3.4", "v1.2.3_4".
>
> 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 unambiguous, I think we can say
it's their problem. (Or our problem to help them with their problem.)
> With a) and b) together (along with the comparisons below), you've described
> version.pm's behavior in a nutshell (but only a single underscore, please).
That was my intent -- I want to work *with* version.pm, but I want to
encourage more limited use of some of the flexibility it provides.
> Before version.pm was added to the core, the discussion on p5p went in the
> direction of "always stringify to the same form that the author originally
> typed" rather than the ->normal form with a leading 'v' (which is how I had it
> originally). Consequently, that is how it works in Perl 5.10.0 (and at least
> until 5.12.0 for a full deprecation cycle).
>
> Now, META.yml could define something different for how _it_ stores version
> numbers, but I can't see how that is going to be any less confusing...
My though was that this recommended standard be just that -- a
standard. Essentially, it's "always express version objects in normal
form to avoid ambiguity". The goal is clear communication, not
round-tripping an original form.
>> For version comparison, Version Numbers of type (b) are converted to
>> type (a) by removing underscores and converting according to the
>> 3-digit Perl version number convention. Example: "1.02" is 1.020 and
>> becomes "v1.20.0", "1.02_03" is 1.020300 and becomes "v1.20.300".
>
> That is an internal implementation detail and should not be exposed (i.e.
> don't
> save the converted version). It would be just wrong to downgrade extended
> versions to numeric or upgrade numeric to extended; it is not what the author
> typed and will be Surprising.
However, if non-perl things are going to cope with version numbers of
type (a) or (b), they'll need to have a way to deal with versions of
both types. If there's a simpler way to express the logic, please do
so. What I propose is a one-way numeric->tuple conversion that always
happens the same way, followed by tuple comparision. No ambiguity.
No heuristics.. Authors being surprised is their own damn fault.
> And is this enforced by Module::Build or whatever tool is used to generate
> META.yml? This won't stop someone from manually mucking with META.yml, but we
> can't help that. All that we can hope to do is make it easy to do it right,
> and
> hard to do it wrong. This is the nature of defensive coding... ;-)
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.
-- David
