David Golden wrote:
> On Sun, Apr 19, 2009 at 4:42 PM, Michael G Schwern <schw...@pobox.com> wrote:
>> And that's that. Have version.pm *always* output at least X.Y.Z. X.Y
>> becomes
>> X.Y.0 or is simply disallowed. Then there's no confusion and no special vX.Y
>> format.
>
> The problem I could see is what to do with alpha versions (an arguably
> bad legacy decision):
>
> X.Y_Z
>
> Is it a number? Or is it a tuple?
It's suck, that's what it is.
It's a number. It's equivalent to X.YZ. It always has been. Leave it that
way, there's no benefit to changing it now.
Do not extend the _Z convention into version.pm. 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 sort of prefer the opposite approach -- anything with a leading v is
> a tuple (splitting on "." or "_"), ideally with at least 3 components.
> Anything without is a number. Anything with multiple dots without a
> leading "v" is an error (but we should do the right thing anyway).
> That seems pretty unambiguous to me.
Let's go through the reasons for having the v marker.
X.Y.Z is always a tuple. It's obviously not a number. What else could it be?
It does not need a leading v.
Same goes for X.Y.Z.A and so forth. So they don't need any disambiguation.
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.
Which brings us down to this: What does allowing X and X.Y as tuples really
buy us that's worth the extra parsing and rules? What about just converting
them to X.0.0 and X.Y.0?
--
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
