[rfc] six-month stable release cycles
mbp at canonical.com
Wed Aug 5 05:14:36 BST 2009
2009/8/5 Ian Clatworthy <ian.clatworthy at canonical.com>:
> Martin Pool wrote:
>> 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.
> I think it comes down to being very clear about what we're hoping to
Right, reading your mail it's clear we could do either of two things
which have a similar shape but different meaning and implications.
A- We release every month and some of those releases get (relatively)
long term support (a bit like Ubuntu LTS vs regular).
B- We release every six months and we ship
snapshots/milestones/betas/what-have-you every month.
It's not black and white -- people may decide the betas are good
enough to use all the time -- but there is a difference.
Case B is a bit like the fine structure of Ubuntu with roughly monthly
betas leading up to a release. On the other hand, just as you said,
the betas are nearly imperceptible to people running the
under-development release because they just get a continuous flow of
updates. I've never heard of someone installing a Karmic beta and
then sitting on it. For use it would be a bit different because there
really is a technical difference between installing releases and
> You've presented a clear case for:
> 1. moving to a 6 monthly cycle as our *primary* one
> 2. having a stable branch with important bug fixes
> Given those changes, what is the driver behind continuing to do monthly
> releases? Who is the audience for those exactly?
I think there's an identifiable segment of active users who will test
betas and report bugs, but who would not be happy tracking trunk
* they can't actually build Bazaar from source (eg Windows) and can
only test installers
* they want identifiable milestones to roll forward or back; or to
say "most of my team is on 2.0.1 but I'm on 2.1beta3"
* it feels too loose
* they appreciate the rhythm of being told things are new and that
they can try them
See Russel's taxonomy of stability earlier in the thread.
If it turns out that nobody uses the betas - everyone uses either
stable or trunk/nightlies - then we can rethink it.
> Our trunk is amazingly stable given we're still yet to lock down our
> network protocol and/or disk format. :-( So users wanting to be beta
> testers can run trunk IMO. I'd argue that the purpose of ongoing monthly
> releases is therefore:
> 1. Empowering leading edge teams dependent on pending features (e.g.
> they need nested trees and it's only available in the non-stable series).
> 2. Providing sync points for plug-in/add-on developers to QA and ship
> 3. Keeping a monthly announcement heartbeat w.r.t. "we're here and we rock".
4. Making sure we actually can release - that there are no bugs that
only show up when you build a package.
5. The comfort factor that it's a change from our previous practice
but not a total change.
In a technical sense the monthlies may be redundant, being essentially
just snapshots off trunk, but I think they do have practical value.
>> I support the principle but I'm not sure where you're going with it.
> To restate your proposal in another way ...
> "Our users want easy access to bug fixes without other changes to the
> core product. They also want a Just Works experience across the *full*
> Bazaar ecosystem. To deliver the first and enable the second, we're
> adopting some standard process patterns: a 6 monthly release cycle and a
> stable branch. These changes will also have other benefits, e.g. better
> synchronisation with Ubuntu releases and, most likely, better roadmap
> I simply want us to be clear that adopting a 6 month cycle for the core
> (bzr) product is a solution to problems, not the requirement itself.
Yes, it totally is. I tried to justify it in the document, but I also
cut out some discussion because, I didn't want to ramble and I thought
it'd happen on the list anyhow.
> Apologies if I'm coming across as picky here but I've seen projects lose
> their way badly by moving to longer release cycles. It's no silver
> bullet and the long term trend across the industry is precisely the
The criticism is appreciated.
I said to John, only half jokingly, that it would be nice to get
Bazaar into Steam
<http://en.wikipedia.org/wiki/Steam_(content_delivery)> so that we
could publish different channels of software and people would
automatically stay up to date: rather than having only a conceptual
slider between nightlies and stable releases, why not have an actual
slider in the UI? (It's not quite so simple.)
I would be interested to go into how projects could lose their way.
To me the biggest risk is that they'll start to say "yeah that's
broken, but we'll fix it before xmas" and then they run out of time.
In the worst cases the tree doesn't even build or pass tests. We
don't do that very much now, and we must not do it. There is an
implicit assumption in saying this that you know how much time it will
take to fix and how much other work you will have, and these are very
A longer major release period is not an excuse to let quality sag
between major releases. The trunk should always stay releasable.
More information about the bazaar