Release schedule plans
justdave at bugzilla.org
Mon Jan 10 11:47:30 UTC 2005
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.
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
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/
More information about the developers