The Core Problem with Parrot Version Numbers

[Allison Randal]

chromatic 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 already had this conversation in another email thread. The Parrot 
tradition is to leave the minor/sub number up to the release manager 
(and architect) depending on significant features. So, we're more likely 
to end up with:

	2.0 (January)
	2.1
	2.1.1
	2.1.2
	2.2
	2.2.1
	2.5 (July)

> 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


Parrot has used N.N.N version numbers since 0.0.1. Changing to a 
completely different numbering scheme just before making a public 
release involves a substantial set of changes to the configuration and 
build system. Changes that we can't adequately test before making that 
public release, because that public release is the next release.

So, there'd have to be a *really* compelling argument for a different 
numbering scheme to make it worth the risk. I don't see a compelling 
argument. The N.N.N versioning is a standard through a significant part 
of the open source world. People will look at it and instantly 
understand "Ah, 2.0 is more recent than 1.0, I might consider 
upgrading." Which is all that really matters.

We could do more with the release names we already have, in addition to 
the standard version numbers. Debian/Ubuntu uses their release names 
quite heavily. Somehow in Parrot release names have never really caught 
on. (I take that as a cultural characteristic.)

Allison