[RFC] Releases planning

[Maritza Mendez]

On Wed, Oct 6, 2010 at 10:15 AM, Vincent Ladeuil
<v.ladeuil+lp at free.fr<v.ladeuil%2Blp 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.
>
> 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.
> +
> +We want to respect the following rules::
> +
> + * the most recent series should release once a month,
> +
> + * 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),
> +
> + * 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,
> +
> + * 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,
> +
> + * 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),
> +
> + * the series are aligned with Ubuntu releases for convenience since we
> +   create a new series every 6 months. This means that we support the
> +   stable series for 2 years. 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.
> +
> +
> +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::
> +
> + * 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
> +
> +
> +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
> +
> +
> +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
>
>

This will run to a few paragraphs.  So proceed at your own risk.  :)

If I may, I think the whole Bazaar community is showing admirable dedication
to understanding what it means to have a  successful release process.  Some
projects (not bzr!) create really useful software and then miss the goal of
actually getting it delivered the way users need.  There's a reason.
Effective release management is hard, really hard.  The challenges are often
more social than technical and the solutions are often energy-intensive.  So
it would be easiest to throw a bunch of files on a server and let smart
users to figure it out for themselves.  Fortunately, the Bazaar community is
smarter than that -- smart enough to recognize that this energy-intensive
process is necessary for the success of the project *and* must be organized
in a way which does not sap more energy than necessary from other
development tasks.

So here's my "vote": I like what has been proposed and I especially support
the idea of having release management scoped for two series: one stable
(maintained) and one beta.  I'm not sure what in the FOSS universe sometimes
drives the call for numerous maintained-by-backport releases, since I
imagine there are more early adopters in FOSS than in the commercial realm.
I do know that in the commercial world we sometimes *think* we want every
major release from our vendors supported forever, but that is inconsistent
with our own desire to retire our own releases as soon as possible to keep
support costs manageable.  And notice that the people who stand up to build
and package bzr are also among the most prolific contributors to the code.
Consider the implications.  The economy of multiple maintained stable
releases -- i.e. shifting near-term cost from customers to vendors -- is
counterproductive in the long run, because the resources needed for
innovation are significantly consumed by legacy maintenance.

Legacy is something I know a lot about.  Legacy is the single greatest
impediment to innovation.  Legacy not only makes it harder to make changes
to your product, it also makes your product less attractive as a platform
for others to build their own products -- like plugins.

The Bazaar community of users and developers -- both present and future --
would be well served by scoping release management to one stable series and
one beta series.  Part of the cost savings could (and should) be invested in
(1) keeping a defined set of "essential plugins" up to date (which should
become easier with fewer releases to target) and (2) documentation.  The
rest of the savings can go into new development.

These benefits do require users to think carefully about how they adopt bzr
into their workflow.  Presumably, everyone using bzr is careful -- otherwise
they probably wouldn't be using any version control.  So what if a serious
bug is introduced in the stable series and I am (properly) not comfortable
running production on the beta series?  Well, every time my teams adopt a
release of any software, we archive a copy.  So if -- for example -- we
really needed to fall back to 2.1 because of an unusually long-lived bug in
2.2, we would be no worse off than we were in 2.1 -- which was already
pretty good.  We're able to do this because we are conservative about
adopting new features.  Although we adopt new stable releases as they come,
we test every new release in a sandbox and typically wait until at least the
*second* major release with "new feature X" before actually using "new
feature X" in production.  Taking the releases gives us the fixes we need,
and being selective about which features we use gives us a margin of safety
against bugs both future and past.  Yes, this is a little more work for us.
But we build confidence in both the feature and ourselves before we turn it
loose with teams of developers.  Effectively, we assemble our own buffer of
static-and-stable-enough-against-our-production-needs set of bzr releases.
If I did not do this, I'd probably be fired the first (maybe second) time
anything went wrong.  As Philip Peitsch recently reminded us on this list,
advocating for new technology can be dangerous, but doing your homework and
documenting it can be a lifesaver.  If we all do whatever homework is
appropriate to our individual environments -- which hopefully we all are
doing already -- then maybe the bzr project can support fewer release series
and invest the savings in even more fixes, features and docs.

Again, thanks and congratulations to everyone who has stepped up to the
challenge of release management -- both for the actual releases and for
openness to discussion about how to make the release process successful.

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101009/57337037/attachment.htm