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