Release timing

[Gervase Markham]

Christopher Hicks wrote:
> On Tue, 18 Jan 2005, Gervase Markham wrote:
> 
>> Remind me why delivering early is a good thing?
> 
> Because delivering late annoys people.

You know what I meant :-)

"Remind me why delivering sooner than six months after the release we 
just did is a good thing?"

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

I'm suggesting that we revisit that logic. One can make an argument for 
"releases every X months", for most sane values of X, but I can't see an 
argument for "freezes every X months". How is the date of a freeze 
important? Surely it's the release date you are trying to hit that's the 
important thing.

>> Aiming for six months apart and hitting seven months is no big deal.
> 
> For an open source project maybe.

Indeed, which is what we are discussing :-)

> I've proposed a solution to this - have some releases be supported 
> longer than others.  Some people need long-term stability (ala RHES).

We could do that, but it might get a bit confusing. Having release X 
still supported while X+1 is not might lead to some strange conversations.
"I need help with release X+1".
"Sorry, it's not supported."
"Yeah, but release X from six months before is supported! How is it hard 
to support release X+1?"
"Er..."

In practice, we'd end up supporting any release more recent than the 
oldest supported release.

But I'd certainly support this model over a "everything supported for 18 
months" model if we are releasing as often as seems to be the plan.

Gerv