On Wed, Oct 6, 2010 at 10:15 AM, Vincent Ladeuil <<a href="mailto:v.ladeuil%2Blp@free.fr">v.ladeuil+lp@free.fr</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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 </blockquote></div> 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