On Thu, Feb 19, 2009 at 4:33 PM, chromatic <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
