Brave new (1.0) world.
chromatic
chromatic at wgz.org
Thu Feb 19 19:09:06 UTC 2009
On Thursday 19 February 2009 10:33:21 Will Coleda wrote:
> If we're calling 1.0/1.5/2.0 -milestone- releases, then they should
> actually be milestones. [1]
They are. They're the milestones after which we start removing deprecated
features.
> If 1.5 is released in July 2009 regardless of what's in the release,
> then calling it a milestone release (and giving it a special version
> number to note the fact) is misleading. If that's the intent, then I
> would recommend dropping the version numbers and just calling it
> "200907".
I would very much like to drop major.minor.patchlevel version numbers and all
of the assorted numerology that goes along with them.
> I would rather see the feature set required for milestone releases be
> fixed (or at least fairly firm), have monthly releases of the 1.0
> milestone branch occur until 1.5 is ready to ship, and then update the
> release date to "whenever it happens.".
I've seen plenty of projects set a hard feature set and slip releases by
months or years. See Debian, Perl 5.10.1, Django, Gentoo....
> [1] equivalent to the pre-PDS world where going from 0.7.1 to 0.8.0
> (e.g.) indicated we'd actually changed something major, but if we had
> gone to 0.7.2 instead, it would have indicated only minor updates. the
> release still occurs monthly, but features drove whether or not it
> made sense to consider it a milestone release or not.
That's exactly the kind of numerology I want to avoid. Version numbers should
always increase. That's all you can say about them.
-- c
More information about the parrot-dev
mailing list