The Core Problem with Parrot Version Numbers

[chromatic]

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