Release schedule plans

[Christopher Hicks]

On Mon, 10 Jan 2005, Gervase Markham wrote:
> Having checked my spam folder, I don't seem to have the original in this 
> thread - did anyone else get it?

Yes.

>>> 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. 
>
> I don't like the sound of that at all. Currently we are managing three, and 
> it's more than enough. I'd argue this is a reason to either extend the 
> development cycle or shorten the support cycle.

I think a mixture of those options would be best.  Folks tend to not want 
to make radical changes to something so critical to their daily lives such 
as bugzilla is for some of us.  Having a long-term stable branch, such as 
2.16 has ended up being inadvertantly, makes it easy for those folks to 
sit with the features they have and avoid radical changes.  So, what if 
every other (or every third as circumstances dictate) "stable" release 
will be a "very stable" release that gets supported for a longer period of 
time.  I'd say that 2.20 or 2.22 should be our next "very stable" release. 
Supporting it for twice as long could mean that the support effort for the 
"stable but not very" releases wouldn't need to be as long.  Maintaining a 
2.18 branch could be cut very short so that folks could focus on 2.20 
maintenance instead for instance.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)