[RFC] Releases planning

[Martin Pool]

It seems like we're converging on:

 * maintain series for 18 months after their .0 release
 * focus packaging on the current stable series and the beta
 * up to the RM whether they prefer to do the source releases
 * target fixes for important bugs, or useful low risk fixes (eg docs)
to the oldest supported series branch they fit into
 * do SRUs for all series, but the most important ones are those for
the current stable series
 * for Windows and OS X package the current series and the beta.  (I
don't think anyone's ever complained about not getting a new 2.1.x
there.)

I don't think there's much point doing a source tarball release if we
are not going to package it.  You might as well just leave the changes
in the branch.  We should adjust the source release rate from old
series to match the rate at which we're willing to do SRUs of them,
which may be 3 or 4 months or more, or it might mean we only do a
release when we fix a major bug.

Let's do 2.3b2 the end of next week.

On 8 October 2010 02:47, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:

> .... cycle.txt !! Indeed :-/ I'm reworking the whole submission to point
> there where appropriate.

Thanks.

>
> Yes, it's roughly coherent, except for the rcs where we say we will do
> them weekly.
>
> I tend to agree that rcs are unnecessary and I think we should freeze
> the API in the last beta and focus on testing and plugin compatibility
> during the last month before the release.

OK, great.  This worked pretty well for 2.2, except that we would have
been better off doing 2.2.1 a bit faster so that

> But in this case, we will have more betas or we started our cycle too
> soon. On the other hand, we can try to release earlier but the 2.2
> series went pretty well for maverick...
>
> So let's say:
>
>  * 2.3.0: 2011-02-03
>
>  * 2.3b5: 2011-01-06
>
>  * 2.3b4: 2010-12-02
>
>  * 2.3b3: 2010-11-04
>
>  * 2.3b2: 2010-10-08
>
>  * 2.3b1: 2010-09-19

I think that's pretty good.  The Natty feature freeze, which is when
we should do 2.3.0, is the 24th February so that gives us a bit of
time. <https://wiki.ubuntu.com/NattyReleaseSchedule>

> And a final remark/question: we have tried to delay the announcement
> until the installers are ready and I think it didn't work.
>
> How about coming back to announcing the source release 5 days after the
> freeze, mentioning whatever installers are available (taking into
> account every know source: windows, OSX, FreeBSD, gentoo, ppas, what
> not) and giving links to more precise source of information (launchpad,
> bazaar.c.c, etc ?).
>
> We could even shorten the 5 days to say 3 days so critical problems can
> be tracked.

Let's do it.  Typically we source freeze on a Thursday or Friday; if
we announce on about the following Tuesday that will give a chance to
both people who tend to work either on the weekend or during the week.

-- 
Martin