Release schedule plans

[Nick Barnes]

At 2005-01-10 11:47:30+0000, David Miller writes:

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?

This sounds OK.

> 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?  :)

I think this is OK.  The branch proliferation isn't too bad.  After
things settle down it's (typically):

trunk : bug fixes and development;
2.28  : bug fixes only;
2.26  : security fixes only;
2.24  : security fixes only.

This is not very dissimilar from what we have handled in the past.
There's some pain in the near future, but that's just the tailing off
of the pain which we're already in (waiting for 2.18, 2.20 frozen,
etc).  The main unknown is: how long is a freeze likely to be?  Given
more frequent releases, and more frequent upgrades of b.m.o, the
overall quality shouldn't decay too much and so the freezes should
stay fairly short.  My favoured software process avoids all freezes by
keeping the trunk releasable at all times (for more information see
<http://www.ravenbrook.com/doc/1999/05/20/pqtcm/>, for instance), but
this might not apply at all well to Bugzilla.

We do need a better ASCIIgram to distinguish between when the branch
is cut and when the release is made, because the extra effort starts
from when the branch is cut (that's when we start having to test every
change in an extra place).  But when the first release is made for a
branch, the rate of change goes down quite a bit.  The ideal ASCIIgram
would also mark freezes etc.

I think it would be a mistake to roll out 2.20 within about three
months of 2.18.  If you plan that then people will wait for 2.20
rather than upgrade twice in rapid succession.

Nick B