gerv at mozilla.org
Tue Jan 18 23:43:33 UTC 2005
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
>> 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?"
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.
More information about the developers