[rfc] six-month stable release cycles

[Michael B. Trausch]

On Wed, 29 Jul 2009, Martin Pool wrote:
> Schedule
> --------
>
> ::
>
> 2.0 --- 2.0.1 -- 2.0.2 -- ...
>  \
>   +--3.0beta1 -- 3.0beta2 -- ... -- 3.0rc1 -- 3.0 -- 3.0.1 -- ...
>                                                \
>                                                 \
>                                                  +-- 4.0beta1 ...

First things first, I think that a 6-month cycle would rock.

That said, I would tend to agree that the major version number should
not be bumped every six months.  My thought would be that any new
default format would be in a (at least 1) 6-month-release before being
promoted to a new default, so that people are comfortable with it and
it's been out for a while, and also so that there is a version out
that would know how to deal with that format before it becomes the
default.  That would make it easily possible to gauge when the next
release would be a major-version-number-bump release.

It'd follow that come time to bump the major version number would be
something of a natural "backwards compatibility breakpoint".  That is,
versions of bzr that are all 2.x would gain new formats, features,
whatever, and mark then deprecated, and all the deprecated stuff would
come out as a part of the 3.x release---much like what GTK+ and GLib
is planning to do with their 3.x release (though they've been in 2.x
for a long time).  The basic idea still holds, I think.

     --- Mike