[RFC] Releases planning

[Vincent Ladeuil]

>>>>> Martin Pool <mbp at canonical.com> writes:

<snip> 

I've taken all the points mentioned into account and will submit
 a mp once we settle on the rest.

</snip>

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

Started as:

Expected releases for the 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. 

As a rough estimate, consider that 2.3.0 will be released in February
2011 and be supported until August 2012. Additional releases will be
made if critical bugs are encountered

    >> +
    >> + * 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?

Yes, I'd like to know too :) Hey packagers ! What do you think ?

<snip/>

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

Right, so 18 months it is. Which means 2.0.6 will be the last 2.0
release then. Good :) There is no bug fixes pending there, only some
tweaks (broken links) in the doc that should have propagated to the web
site already. We can do a final release if really needed.

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

I discussed at length with pitti about the 2.0.6 SRU
(https://bugs.launchpad.net/bzr/+bug/582656) and I think we should
indeed focus on 2.2 and 2.3 and do only source releases for 2.0 and 2.1.

That is, depending on the OS we're packaging for, most of our efforts
should be on the *last* stable release (2.2 today) and on the upcoming
release (2.3 today).

I still think we should finished the current SURs, but after that, we
can alredy discuss:

- still backport or target critical fixes to 2.1 (no more 2.0 backports
  unless a very strong need arise) but we won't *package* it anymore,
  we'll do only source releases.

- still backport bugfixes targeted at debian or Ubuntu for the 2.0
  series, but in the packaging branch instead of our lp:bzr/2.0 or
  lp:bzr/2.1 branches... which would make a good dogfood exercise...


For windows and OSX, where we package more than bzr, I'd also like us to
focus on 2.2 and 2.3 exclusively as I think there are less cases where
people can't follow the stable releases, but again, it's up to the
packagers to decide whether or not they want to release installers for
older stable releases.


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

Almost, I was saying that instead of waiting for 2.0.6 for hardy, people
could use the stable ppa and update to 2.2, but I think your idea is
better :)

We could indeed create a ppa for each stable series and update it when
we release a new stable series. That would ensure that our users get a
coherent set of plugins with bzr itself (which the SRUs don't offer).

If we go this route, I would like to relax the relationship betwen
announcing the release and the availability of up-to-date packages.  It
makes even more sense for ppa than for installers since the user will be
prompted when the ppa is updated *anyway*. May be bzr-explorer can also
gain a 'check updates' feature for windows and OSX...

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

Ok. I moved it to whats-new instead.

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

Agreed, I forgot to mention it but I consider lp to be more
authoritative in this respect.

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

See below.

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

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

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.

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


Thougts ?

<snip/>

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

Yes, the pattern is not precise, it's more a manual affectation trying
to respect the rules described in the proposal. So there is probably
*more* releases than will in fact exist.

<snip/>

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

Some thing. I've been pessimist and expected a lot of critical bugs.
Plan for the worst so you don't panic when it occurs :) I expect less
releases here too.


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.

Thoughts ?

         Vincent