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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
