[rfc] six-month stable release cycles

[Ian Clatworthy]

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

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

3. Keeping a monthly announcement heartbeat w.r.t. "we're here and we rock".

Are there more?

Are those goals important enough to continue doing monthlies? If so, are
they important enough for a short stabilisation period and/or some other
process tweak, e.g. explicitly landing higher risk changes earlier in
the month?

> 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.
>
>   
You're right - "milestone" sucks as a name. The more important point is
whether they are really betas (as proposed) or not (our current
monthlies). If they are going to be betas, then naming is easy. If we
want to continue doing better than that, then we can worry more about a
suitable name ("preview" works for me).
>> Fourthly, let's double-check we're being driven by user needs, not
>> necessarily their expectations. 
>>     
>
> 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
planning".

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.

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

Having said that, it's the right thing for us to do right now and I'd
like to reiterate my support for your proposal. Let's be really
carefully not to gloss over details though and to be crystal clear as to
what the purpose of each process stage is.

Ian C.