[rfc] six-month stable release cycles

[Ian Clatworthy]

Brian de Alwis wrote:
>
> FWIW: The Eclipse project avoid numbering issues by calling
> development releases "milestones".  Each formal release consists of a
> milestone period for introducing new functionality (e.g., 3.5M1,
> 3.5M2, ...), followed usually a set of release candidates for ironing
> out bugs (3.5RC1, ... 3.5RC4), of which the last is (hopefully)
> promoted as the GA for general availability (R3.5).  

Having been away (sick) for a week+ now , I hope it's not too late to
add my thoughts on this important thread ...

Firstly, congratulations to Martin for kicking this off with a really
well considered and written proposal. The large number of positive votes
on the idea says a great deal about "It's time" w.r.t. needing a stable
branch to meet the needs of our user base as Bazaar reaches 2.0.

Secondly, I'd like us to follow the scheme used by Eclipse and call our
"monthlies" milestone, not beta, releases. That implies a pretty
important change to Martin's proposal though: we continue to make a
"milestone branch" a week before it gets announced. Yes, that implies
(1) a "milestone rc" and (2) increased Release Manager load. If that is
honestly too much of a burden, then we ought to change our cycle from 4
to 6 weeks, not drop the mini-stabilisation period. (Appointing an RM
for 6 months may help too.) BTW, if we simply cut a release every 4
weeks as proposed, then they *are* betas and that, IMO, would be a QA
regression.

Thirdly, Just Works needs to mean that from the installer onwards, if
not earlier (the website). Aaron's suggestion ("go gold" a separate
announcement to "it's ready") is the minimum required to start improving
that part of our culture. As a community, I *hope* we're realistic about
where we're at w.r.t. Windows and OS X today, i.e. frankly, we still
feel like a Linux tool that can run on those platforms rather than a
genuinely native-ish tool. I'm sure that will change a lot over the next
6 months as we focus more on user experience, but I feel it's important
that our *processes* start supporting/encouraging this sooner. Step 1 is
putting more effort into getting the native installers done and "QAed"
before we go 2.0. (I'll post more about what I'd like to see here
separately.)

Fourthly, let's double-check we're being driven by user needs, not
necessarily their expectations. In the majority of cases, those
expectations are often based on central-VCS-based processes,
non-automated testing, etc. DVCS and pre-commit CI change the software
development game and we should be a poster child for doing things in a
better way. In fact, we ought to think about changing the deployment
game far more than we are! [1]

On the whole though, a large +1 from me on the general direction.

Ian C.

[1] For example, our installers could install required dependencies and
unpack bzr branches of bzr and the bundled plugins. If those branches
had stable branches on lp as their parents, then upgrading - even on
Windows - would be "bzr pull", not the whole crazy uninstall/reinstall
dance. Of course, "bzr pull" would be wrapped by a menu option in Bazaar
Explorer called "Software Update", Explorer would be bundled in our
Windows and OS X installers, and ... another time.