[rfc] six-month stable release cycles

[Martin Pool]

2009/7/31 Stephen J. Turnbull <stephen at xemacs.org>:
> Robert Collins writes:
>
>  > I suggest "next" rather than beta. It has the same connotation of 'not
>  > the stable release', but for me isn't a negative label, whereas beta is.
>
> Please don't do that.  You can fool some of the people some of the
> time, of course, but if you don't use the standard terminology sane
> people will be suspicious of a marketroidery.  And they'd be right.

I agree.

> Bazaar's quality control is good.  But as long as you have new
> features[1] in every release, every release is a "first beta", and you
> have no stable releases.  That is the problem, and Martin's proposal
> addresses it in a blunt but effective way, by basically freezing the
> UI and API at the current beta.
>
> Note, this means that a "point oh point oh" release is the last beta,
> *not* the first stable release.  In this process, "stable" only really
> starts to have meaning with "point oh point one" -- if I were Martin,
> I'd schedule a x.0.1 release for one month after the x.0.0 release,
> even if the only patch applied is to the version number :-).  This is
> the way everybody thinks about "point oh" releases anyway; I think it
> make sense to admit it formally.

I think by this you mean that the only difference between the
development and stable releases is that the stable releases will then
get bugfix-only updates later on.  So yes, I agree that's the main
distinction -- aside from the numbers of course, and the way we
announce them, and that we might will do some amount of rc period for
stabilization prior to the actual release.

The Python case is a lot like ours, unsurprisingly - they basically
can't and don't make strong promises about stability from 2.x to 2.y -
but we can at least have a stable 2.x.1

-- 
Martin <http://launchpad.net/~mbp/>