Release timing

[Christopher Hicks]

On Tue, 18 Jan 2005, Gervase Markham wrote:
> Remind me why delivering early is a good thing?

Because delivering late annoys people.

> If we expect a freeze time of 1 month for 2.20, we should set the freeze 
> date to be five months from last Sunday - i.e. June 16th, for release in 
> mid-July. Then, we will be making releases approximately six months 
> apart.

Dave has indicated that the freezes will be timed, not the releases so 
basing dates off of the release date does not fit with the logic that Dave 
feels was agreed upon.

> Aiming for six months apart and hitting seven months is no big deal.

For an open source project maybe.

> Aiming for and hitting five months apart is a big deal; with 18-month 
> support cycles (are we still planning to do those?) we would have five 
> branches on the go at once :-(

I've proposed a solution to this - have some releases be supported longer 
than others.  Some people need long-term stability (ala RHES).  Have other 
releases be supported until two releases have been made.  So if 2.20 
became a "long-term support" release, it would continue to be supported 
for three years.  During that time, six releases would come out (two per 
year).  So at any one time two "short term" releases would be in support 
and one or two "long term" releases.  This way there would never be five 
branches being supported at once and usually there would only be three - 
the long term one and two short term ones.

-- 
</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)