[rfc] six-month stable release cycles

[Stephen J. Turnbull]

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.

As it is, users and developers of projects related to bazaar are
always at risk of being seriously surprised (Russell Winder and
Alexander B come to mind as being vocally surprised types :-).  That's
not stability, that's beta, and the negative connotation of "beta" is
inherent in the process of introducing new features to general users.

The fact is that the software released by the current Bazaar process
is beta software, in the software engineering sense.  The branch you
release from is continuously suffering from API and UI changes, and
there is no true stable branch which only receives bugfixes.  Compare
to Python, with 6 open branches at any given time, of which 2 never
release (they're just places to collect security patches for those who
depend on very old versions), 2 are truly stable (no new APIs, and no
changing correct behavior of old ones either), and 2 are in
development.  The platinum standard of OSS process!

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.

Again, this is *not* an issue of quality control that could be
improved inside of Bazaar's process.  It's a matter of putting the
code out there, and defending yourselves against the slings and arrows
of Mr. Murphy.  You may very well have gotten it right in the "point
oh" release, but only time can prove that.  And users all know it,
even if the developers don't!

Unfortunately laying out the definitions like this doesn't solve the
problem that Matthew and Michael face, but IMO it makes it clear that
it is a problem of substance, not of terminology.

Stable-means-read-my-lips-no-new-features-ly y'rs,


Footnotes: 
[1]  Decided just before release.  In many definitions of beta, it's
OK to introduce the implementations of a few new features during the
beta process as long as they have been fully specified and are
promised for the release.  But there are no such specs (ie, fixed in
advance) and promises in the Bazaar process at this point.