The Core Problem with Parrot Version Numbers

[chromatic]

On Thursday 19 February 2009 16:09:36 Andrew Whitworth wrote:

> Even if we don't like the specific implementation discussed here (it's
> very similar to what Ubuntu does, but I suggest we stay away from the
> asinine alliterative adjectives) there are plenty of ways to take this
> same concept and make it less whimsical. I've known other programs
> (Matlab being an example near and dear to my heart) that used the year
> in the name: 2009r1 .. 2009r12, 2010r1, ... We could also tack on
> patch numbers and other stuff like 2009r5.01 or whatever we want. I'm
> not necessarily recommending this scheme, but it is an example of
> chromatic's idea with years instead of alphabetical names. In any
> case, I think we definitely should ditch the X.Y.Z scheme since it
> just doesn't fit our release model in any sense.

One drawback of raw year numbers is that it doesn't encode the biannual 
release structure.  The more numbers and letters you stick with a scheme, the 
harder it is to parse out meaning (and disambiguate between them).

I understand the disappeal of the whimsical naming scheme, but it *does* have 
a lot going for it in the mnemonic sense.  You could explain it to a third 
grader, for example.

-- c