On Mon, Apr 20, 2009 at 4:17 PM, Michael G Schwern <schw...@pobox.com> wrote:
> Do not extend the _Z convention into version.pm.
Too late. It's there. qv("1.2_3") -> v1.2_3
I wish it wasn't that way, but it is. Thus, my suggestion that "v"
always indicate a tuple.
> The state of a release does
> not belong in the version number. Its an inflexible system that complicates
> version comparisons even more. We already have a sane means of recording
> release metadata, it is META.yml. Stick the release info in there.
I agree entirely, though I don't think a convention has been added to
META.yml for it.
> That leaves X and X.Y. The only reason for the leading v is to disambiguate X
> and X.Y, the numbers, from X and X.Y, the tuples. If we disallow X and X.Y
> tuples, there's no more ambiguity, no more v and no more special parsing.
We can't disallow them, short of time travel.
My proposal for using a leading "v" as the standard is based on the
fact that version.pm *already* does it and it solves the X.Y_Z
problem. A "v" also ensures that it can only be interpreted as a
string, not a number. That makes for a nice, clear-cut case. We
*know* with absolute certainty that "v"-whatever is intended to be
tuples. We never have to guess. That seems like a nice feature, as
it's a clean break with the past.
There are two inescapable problems:
(a) how someone should convert from a numeric versions to vX.Y.Z
without screwing up their ascending sequence
(b) how to compare vX.Y.Z to a legacy X.YYZZ
Those will still need heuristics, documentation and a big stick.
-- David
