Brave new (1.0) world.

[Geoffrey Broadwell]

On Thu, 2009-02-19 at 11:09 -0800, chromatic 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.

That's not a milestone in the sense that I think is most commonly used
-- it's more of a "deprecation boundary".

> I would very much like to drop major.minor.patchlevel version numbers and all 
> of the assorted numerology that goes along with them.

It may be numerology, but it's numerology with fairly strong conventions
-- and thus provides a useful cognitive structure for communicating our
intent with each release.
 
> > 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....

Debian's problem is not a hard feature set; key features often go in
(relatively) quickly into a new release cycle, and many more are dropped
later because they don't make it in time.  The Debian delays are because
of A) a hard stability requirement before release, and B) constant
squabbling about binary firmware blobs that require invoking certain
very slow procedures in their constitution.

I can't speak to the other projects, though; they may indeed be blocked
by hard-headed feature requirements.  Personally I think parrot's
requirement should be "*some* set of big important features is ready",
not "this *exact* set of features is ready".

> That's exactly the kind of numerology I want to avoid.  Version numbers should 
> always increase.  That's all you can say about them.

That's a fine stance, but it completely ignores culture -- and in
particular, a culture that Parrot itself has been a part of for years
now.  If you want to completely remove any useful information about the
release other than order, then release date makes a fine "version", as
Will has pointed out.  But you'd damn well better have some other very
terse and easy to understand way to tell people whether they should care
about upgrading.  (Yes, I know, you'd be very happy if people *always*
upgraded.  But you're the same one advocating breaking backwards
compatibility regularly, so you can't have both.)


-'f