The Core Problem with Parrot Version Numbers

[Will Coleda]

On Thu, Feb 19, 2009 at 4:33 PM, chromatic <chromatic at wgz.org> wrote:
> The core problem of version numbers (setting aside all of the tired and
> fallacious numerological arguments) is that our deprecation and support
> periods are six month cycles, and that there are only five whole numbers
> between 1 and 5.
>
> In other words:
>
>        1.0 (January)
>        1.1
>        1.2
>        1.3
>        1.4
>        1.5 (May^H^H^HJune, oops!)
>
> We can keep arguing over version numbers, as if they had any effect on our
> calendar-based support, deprecation, and feature-planning cycles (and let me
> assure you, they don't), or we can drop the silly idea that version numbers
> mean anything and use the calendar to reflect that we use the calendar to plan
> our support, deprecation, and feature cycles.
>
> Alternately, we could use code names to refer to the biannuals, which appeals
> to my sense of whimsy:
>
>        Parrot 1.0 is Parrot Budgie
>
>        March 2009:     Budgie 1
>                                Budgie 2
>                                Budgie 3
>                                Budgie 4
>        July 2009               Cockatoo 1
>                                Cockatoo 2
>                                Cockatoo 3
>                                Cockatoo 4
>                                Cockatoo 5
>                                Cockatoo 6
>        January 2010    Dusky 1
>
>        ....
>
> This scheme takes advantage of the biannual nature of our cycles, better
> indicates the types of changes that the users Todd Olson mentions can expect,
> and has the advantage of not throwing a stream of numbers such as 20090417 at
> people.
>
> I don't think it's workable to try to encode information about bugfixes
> versions features into version numbers, nor do I want to have a monthly debate
> over how major a release is -- especially as I was happily and productively
> working on the milestone task of reviewing TODO and SKIP tests before this
> thread sucked me in.  (Okay, it was my choice to dive in... but still.)
>
> -- c
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

I like this scheme:
-- it lets us easily reset to calendar intervals after the first release;
-- it avoids embedding information into the release #. (we were trying
to fit in a few potentially incompatible things there.)

I assume the b,c,d progression is intended and meant to show order
(e.g. D>C, so Dusty is always newer than Cockatoo); I had a concern
about what happens after Z, but pmichaud++ pointed out we'd simply
reset (like for hurricanes - reset initial letter but avoid reuse of
names), and users wouldn't have to keep the whole history of release
names in our head for comparison; knowing that the next A-named
version was newer than the last Z-named version is not a big lift for
our end users (and one they'd only face every 13 years.)

+2

-- 
Will "Coke" Coleda