Brave new (1.0) world.

[Will Coleda]

On Thu, Feb 19, 2009 at 2:09 PM, chromatic <chromatic at wgz.org> wrote:
> 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.

Ah. Here's my cognitive problem, then.

We're not defining milestones by added features, but by what we can remove?

>> 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....

Ok. Then we should make it clear that the features that we have listed
for the various releases in Roadmap are just suggestions. That's not
how I'm currently reading that.

>> [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

Given the change in what a big/stable/milestone release means after
1.0, I'm fine with that.

Unfortunately, with milestone releases numbered (e.g.) 1.5, we  can't
avoid the major/minor/patchlevel scheme, since we don't have enough
numbers. Any suggestions on how to resolve the desire to avoid special
numbers and yet keep milestone releases (which are now just date based
and driving deprecations) with an obvious numbering scheme?

I know we had another entire thread devoted to this subject, but that
only ended happily because we thought we'd have releases like "1.2.0"
to indicate a major feature land like we did pre-PDS. If your plan
doesn't include that sort of release numbering, what do you intend to
replace it with?

We also need to really well document the plan here, because as a user,
if I see parrot 2.0 vs. parrot 1.0, and it doesn't have any new
features, I'm going to be very confused. Proof: I'm already confused.

-- 
Will "Coke" Coleda