Release schedule plans

[David Miller]

A few of us had a pretty good conversation late last night on IRC about 
our plans for current and future releases.  I think it's definitely 
worth a read and further discussion.  Nothing discussed here has had any 
final decisions made yet.

http://www.justdave.net/bz/irc20040110-releaseplans.html

A quick summary of some of the ideas that were hashed out (but it'll 
make better sense if you actually read the log a the above URL) :

1) Should we abort the 2.20 freeze and make our March 15 freeze be for 
2.20 instead of 2.22?

This sits at an undecided Maybe from the existing discussion on IRC, but 
leaning towards releasing 2.20 in the immediate near future anyway, 
thanks to the discussion in point number 5 below.

2) Should we attempt an "eased transition" into the 6 month cycle where 
we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would 
freeze March 15 as above), then 9 months for 2.22 (making it Jan 1 
2006), then 6 months from there on out?

We generally decided that the "overlapping freezes" was very unlikely to 
ever happen again, so the 9 months for the next release probably 
wouldn't be necessary.

3) Our newly frequent releases (if we can stick to them) are going to 
create a lot of branches to simultaneously maintain.  Should we have 
branch managers for each branch?

I pointed out that we attempted to do this in the past, and nobody ever 
took me up on it.  Most of the people with the motivation to do such a 
thing (at least when I asked around last time) like to stay on the tip, 
and would feel constrained quickly if they had to stay on a branch.  I 
still kind of like the idea if we can find people to do it though.

4) b.m.o upgrade schedule was discussed.

I felt that b.m.o should stay on the "current stable" branch from this 
point onward, with it upgrading to the next stable branch as soon as the 
branch was cut (coinciding with the rc1 release for that branch).  This 
would allow b.m.o to update frequently (every week or two if needed?) 
within that branch to continue to pick up bugfixes without it being a 
major deal to upgrade and with minimal chance of picking up regressions. 
  The 6 months between getting new features would be much quicker than 
b.m.o's historical upgrade frequency, so mozilla.org folks would still 
be happy.  Since b.m.o still, to this day, finds 90% of our release 
blockers, giving them our first release candidate should get this part 
out of the way quickly both for them and for us. :)

5) What kind of branch lifetime and support level should we provide?

Our previous branch management policy was brought up...  originally, 
*nothing* got checked in on a stable branch unless it fixed a 
regression, a security issue, or a dataloss problem.  Recently we've 
been a bit lax with that, allowing minor bugfixes to be checked in on 
the branches as well.  It was felt that this was at least partially the 
fault of the 2.16 branch being so freaking old (3 years!) and still 
supported as the "current stable release".  Everyone pretty much agreed 
that we need to set up some clear-cut rules for what can go on the 
branches when, and get those rules posted on the website for reference. 
  The idea that everyone (that was there) seemed to like the best was to 
go ahead and provide general bugfixes on the stable branch for 6 months 
after release, and after that 6 months, provide *only* security and 
dataloss fixes for an additional 12 months.  This would give each 
release a security-supported lifetime of 18 months.

Correcting for accuracy from the IRC log (after I drew the little 
chart), this would actually give us 6 active branches (eek!) at one 
point (counting the trunk), but we'll always have 4 in the long run once 
the dust settles.  This is easier to visualize with said little chart:

== Bugfixes provided
-- Security only

      Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
2.16 --|
2.18 ======-----------|
2.20 =======-----------|
2.22   |======-----------|
2.24         |======-----------|
2.26               |======-----------|
2.28                     |======-----------|

We might call it 3.0 at some point in there, but these are good enough 
examples to get the gist of it.

OK, that about covers it.  Discussion?  :)

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/