Release schedule plans

[Gervase Markham]

[Apologies for the lack of threading; I was missing the message and so 
had to cut and paste from the archives.]

> 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.

It seems that we have three choices:

a) Release 2.18 and release 2.20 soon afterwards
b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
c) Abandon 2.18 and just release 2.20

 From the point of view of our customers, who don't want to upgrade too 
frequently, and from our point of view, where we don't want to have to 
maintain too many branches, a) is the worst case scenario.

It puts two releases close together, which will affect maintenance and 
release management for at least 18 months. It also means we have a 
confused story. "Upgrade to our shiny new 2.18! It's the first stable 
release for three years! Except unless you can wait another month or 
two, in which case 2.20 is coming right along behind it, and it's 
better." It's like buses. You wait three years for one...

So IMO we should either unfreeze the trunk and develop some more (which 
seems reasonable; we don't have that many new features yet anyway) or we 
should scrap 2.18 altogether and release 2.20, if it's so close.

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

Remind me again why we are so keen to do a *six* month release cycle? 
What was the rationale there?

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

<snip>

I agree with everything that was said, apart from the fact that we 
should upgrade just _before_ we branch rather than just after. That 
means that, if there's more fallout than expected, we don't have to do 
lots of work applying patches to two near-identical branches, and the 
people who would fix the fallout aren't distracted by checking shiny new 
features into the trunk.

Gerv