[RFC] Releases planning

[Martin Pool]

On 7 October 2010 04:15, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
> I've been looking at how we released bzr in the past for the 2.0, 2.1
> and 2.2 releases.
>
> Now that we've started our fourth series, 2.3, I though it was time to
> define a bit more formally the rules that govern *when* we release.
>
> As a new RM, I've made some mistakes by trying to release simultaneously
> 2.0.6, 2.1.3, 2.2.1 and 2.3b1 which are all in a different part of their
> life cycle.

Hi, thanks for looking at that.

Just as a documentation style thing, I'd avoid making statements like
"we currently maintain four series" because it's going to change a bit
over time as things go in and out of support.  You could say "as of
October 2010".  Maybe this is just pedantry, but I think it's
disconcerting when there's docs that are obviously out of date and
don't know it.



>
> I'd like to amend our doc/developers/releasing.txt with the following
> patch, but I'd like even more your feedback there !
>
> === modified file 'doc/developers/releasing.txt'
> --- doc/developers/releasing.txt        2010-09-24 09:56:50 +0000
> +++ doc/developers/releasing.txt        2010-10-06 16:53:46 +0000
> @@ -24,6 +24,122 @@
>
>      bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
>
> +Release provisional planning
> +============================
> +
> +We currently maintain four series. Concurrently releasing them all at the
> +same time makes it harder to shorten the delay between the source
> +availability and the package building longer than necessary (we delay the
> +official announcement until most of our users can install the new release).
> +
> +In order to continue to do time-based releases, we need to plan the
> +releases by series to minimize the collisions.
> +

The axiom here is that it's easier not to do multiple releases in the
same week.  I can see why you think this but in some ways I have found
it easier to spend a week just doing release work, then to be done
with it.  Also, if we've fixed a genuinely critical bug, perhaps it is
worth updating every supported series as soon as possible.  I don't
mind much either way.  Perhaps it can be left up to the discretion of
the RM?  Or perhaps people would prefer to know what to expect?

> +We want to respect the following rules::
> +
> + * the most recent series should release once a month,

I guess you mean the development series, that's currently in beta.

> +
> + * the most recent stable series should release every other month (based
> +   on the amount of bug fixes, this can be shorter or longer depending
> +   on the bugs importance),

ok

> +
> + * previous series should relesase on a a regular basis without
> +   interfering with the most recent series with a decreasing order of
> +   priority (again this should be based on bugs importance and user
> +   feedback,

typo, but otherwise ok.


> + * the death of a series should be planned ahead of time. 6 months
> +   should give enough time to our users to migrate to a more recent
> +   series,

ok.

Of course this does not mean there needs to be a release at the end of
the series, just that before the end date we _could_ possibly put out
another release if there was a sufficiently important fix.  Beyond
that date, we won't even land changes on that branch (unless something
causes a miraculous resurrection.)

Let's put that table into some user-accessible documentation?  "What's
new in 2.3" would not be a bad place to describe when 2.3 will end.

> +
> + * there should not be more than 2 releases in the same week (but the
> +   Release Manager is free to ignore this (get in touch with packagers
> +   though),

Do packagers prefer this rule?


> +
> + * the series are aligned with Ubuntu releases for convenience since we
> +   create a new series every 6 months.

Right

> + This means that we support the
> +   stable series for 2 years.

That doesn't seem to follow, unless you take it as an axiom that
they're supported for 2 years. I think we've previously said "at least
12 months".  Ubuntu non-LTS releases last 18 months.  Will people care
if it lasts longer?

I asked about this on the blog a while ago
<http://bazaarvcs.wordpress.com/2010/03/25/how-long-stable-series/>
and people seemed to generally want support for either (A) 18 months,
or (B) the lifetime of the host Ubuntu release.

The simplest answer would be to define it as 18 months.  Four parallel
series seems to be reaching diminishing returns.

Remember if there is a truly critical or security bug, we can always
make an exception, or the Ubuntu LTS team can cherrypick that fix.

> +   Note that we also propose the most recent
> +   stable series via the ppa, so whether we keep supporting LTS directly
> +   or via the ppa is still an open question.

That sentence is not very clear, but I think you mean that when an LTS
is say three years old, the only way to get new fixes will be to
upgrade from the PPA.  I think that makes sense, especially if we have
a ppa for each bzr series.

> +
> +
> +2.3 series
> +----------
> +
> +The 2.3 series has entered the beta phase and 2.3.0 should be released soon
> +enough to be included into Natty Narwhal. This gives the following expected
> +releases::

I would not list the releases in here, at least not in this form.
It's not easy to see the intervals and the dates are probably overly
precise -- as you acknowledged below.  If we want draft dates, let's
put them in lp milestones and/or an RM mail to the list about upcoming
releases.  But they're useful for this discussion.

The point is: 2.3: monthly betas up to a 2.3.0 release in Februrary.

I believe the agreed plan is that we will do an API freeze in the last
beta, then make a 2.3 branch, then release 2.3.0 directly off that
branch, then possibly a 2.3.1 etc into Natty.  rcs are unnecessary
overhead since the final source is normally good.

This reminds me, we should check what you say here is consistent with
cycle.txt, and perhaps it should go into that.

> +
> + * 2.3.0: 2011-02-03
> +
> + * 2.3rc2: 2011-01-06
> +
> + * 2.3rc1: 2010-12-02
> +
> + * 2.3b3: 2010-11-04
> +
> + * 2.3b2: 2010-10-08
> +
> + * 2.3.b1: 2010-09-19
> +
> +2.2 series
> +----------
> +
> +The 2.2 series is the current stable release and is included in Maverick
> +Meerkat. The planned releases are::
> +
> + * 2.2.3: 2010-12-16
> +
> + * 2.2.2: 2010-11-18
> +
> + * 2.2.1: 2010-09-17
> +
> + * 2.2.0: 2010-08-06

Again, I think the main point is to say that it will expire in April
2012, or whatever it's going to be.

I don't see what the pattern is here?  You said "every other month"
meaning every two months, but the gaps are irregular.

> +
> +
> +2.1 series
> +----------
> +
> +The 2.1 series is the stable release included in Lucid Lynx. The planned
> +releases are::
> +
> + * 2.1.6: 2011-01
> +
> + * 2.1.5: 2010-12
> +
> + * 2.1.4: 2010-11
> +
> + * 2.1.3: 2010-09-16
> +
> + * 2.1.2: 2010-05-27
> +
> + * 2.1.1: 2010-03-02
> +
> + * 2.1.0: 2010-02-11

Again, I don't see why we would have releases in November, December and January.

> +
> +
> +2.0 series
> +----------
> +
> +The 2.0 series is the stable release included in Karmic Koala. The planned
> +release are::
> +
> + * 2.0.7: 2011-03 will be the last release for the 2.0 series.
> +
> + * 2.0.6: 2010-09-16
> +
> + * 2.0.5: 2010-03-22
> +
> + * 2.0.4: 2010-01-21
> +
> + * 2.0.3: 2009-12-14
> +
> + * 2.0.2: 2009-11-02
> +
> + * 2.0.1: 2009-10-14
> +
> + * 2.0.0: 2009-09-21
> +
>
> We may not want to embed so many dates for each series in this document,
> thoughts ?
>
> To put things in perspective, I've also tried to simulate these rules in
> the attached document.
>
> *Don't take it litteraly, it is *not* meant to represent the official
>  release dates in any way*.
>
>  Vincent
>
>



-- 
Martin