[rfc] six-month stable release cycles

[Martin Pool]

2009/8/4 Ian Clatworthy <ian.clatworthy at canonical.com>:
> 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 ...

I'm glad you're back and thanks for posting.

>
> 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.

I don't want us to tackle the question of a stable branch by just
piling on more work, but also to look for where we can satisfy people
while doing less.

I'd like to see if we can keep our trunk always ready to do a release
without needing a special stabilization period, which is a kind of
overhead.  There's also the fairly substantial overhead of actually
making and announcing the releases.

If it turns out that our monthlies are too-often broken then we can
look at having a stabilization week, or we could perhaps work out how
to have them not break so much.  Most releases have not needed fixes;
those that have often need them for last-minute merges suggesting we
need less rushing and more hustle.

Having monthly rcs would help people who want to run the monthlies but
not willing to run their rcs, and I think that's slicing it too thin.

So yes, they are betas.  I think the name 'milestone' is a bit
noncommittal about what kind of release it is like those awful
variables called 'data', and it makes users get into knowing what M0
is vs M5.

>
> 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.)

Yes, I agree we should have a code freeze before the release
announcement, it's a great idea.

>
> 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]

I support the principle but I'm not sure where you're going with it.
To me it seems pretty clear people do have a strong desire to get bug
fixes without having disruptive changes or broken plugins.

I think we're doing pretty well as far as automated testing, but not
so great as far as automatically releasing.

> [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.

Those would obviously need to be branches that included the compiled
binaries.  It's an interesting idea, though I'd want to be clear in
what way it's better than the many existing packaging systems.

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