[rfc] six-month stable release cycles

[Martin Pool]

2009/7/29 Martin Pool <mbp at canonical.com>:
> A longer stable cycle has often been requested.  I think we should do
> it, now, along the lines of this document.   (It's in devnotes and
> also as a pdf for those who like it that way.)

I'm really thrilled at the positive reception and suggestions, and at
the prospect that when we do it, Bazaar can both make users happier
and make some code evolutions easier.

I'm going to answer these in one mail because the thread is quite fanned-out.

I'd like to give other active developers a chance to comment on it if
they wish before we say it's finally settled, and of course it's a
plan not a straightjacket, but I think it's basically set and we
should start doing it.

I agree that bumping only the first digit every release may seem
unclear.  As John suggests, we can decide at the start of a cycle
whether we're aiming for a 3.0 or a 2.1, and do that.

I do think marking the betas as betas rather than as say 2.90 better
conveys the message that they have different support guarantees.
There may be a lot of change in 3.0beta2 whereas you would expect 2.91
was stabilizing.  On the other hand, pace Eric, I think calling
something 3.0rc1 makes an appropriately stronger statement that we
really do not want to change anything than calling it 2.95 would do.

In previous experiments with having freeze periods it caused
noticeable waste and unhappiness.  Therefore I think we should always
have an open trunk, so that if someone comes up with a great new
feature they can always land it there (modulo reviews and automated
tests and so on.)  There might be times where most of our effort is
focused on a release branch, but changes that aren't appropriate for
it will never be out in the cold.

I think Aaron's suggestion of separating the code freeze date from the
announcement date makes sense, so that when we announce we do have
binaries for the key platforms.  We don't want the RM's job to be any
harder or longer than it already is, so their job is to get the source
tarball out, notify the package builders, and then give the platform
maintainers a window of a few days to make the release tarball.

This way we do get binaries on the day of the actual release, but we
don't insist that the RM synchronously builds and tests a mac
installer and a Windows installer etc.  If it turns out there is a
problem in the upstream source that prevents building an installer for
a particular platform it will give us a chance to cycle there.

In general we will build and test binaries for the rc before the code
freeze for the final release so that gives a Window for general
testing.  Obviously if we did not have binaries out reasonably early
in the rc process we would not get very good test feedback on that
platform.

As John alludes to, there really is something different or difficult
about packaging and testing of binary installers compared to regular
development work.  Obviously they are very important, especially on
binary-oriented platforms, but they can also cut deeply into
development effort.  It's not something that people can just take for
granted that the core team or the Canonical-employed developers will
do.  So I think the thing is not to argue about how important they
are, but look for ways we can scale this up and scale it out - there
have been some good steps recently as far as the relative speed with
which Mac and Windows installers have come out, and progress towards
making most of them more automated.

If John's feeling burnt out on it, will someone who cares a lot about
the Windows installer take the lead on it?  You don't need to know a
lot about Python or development, you just need to commit to doing it,
at least for one cycle, and the core team will help you through it.  I
don't think it's inherently a destructive job, but it is a grind for
someone who's just finished the code on the release and wants to get
into their work for the next one.

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