Release timing

Gervase Markham gerv at mozilla.org
Sun Jan 23 12:48:34 UTC 2005


Christopher Hicks wrote:
> It may not be the ideal thing, but it seems better than the 
> alternatives. Getting on a release rhythm may entail some occassional 
> irritation, but I do think its worth the trouble.

This comes back to the question we are discussing in the other thread - 
why have we picked a rhythm which requires this particular irritation, 
when it's not necessary to do so?

>>> 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.
> 
> Having the freeze dates be something that people know from remember when 
> it happened last year seems more important than exactly when we release 
> to the world.

That's certainly unusual logic - in that I don't know of any other 
project which puts value on having _freezes_ at the same time each year.

> As long as there's been a release in the last year the 
> user is going to feel like we're making progress, but the developers 
> care about the exact freeze data because presumably they have something 
> that they want in before the freeze.

I completely agree that developers care about what the freeze date is, 
but I don't agree that they care that it's the same calendar date as the 
previous year.

> Instead of "er" you could say "Release X and X+3, and X+4 are supported, 
> please help us to minimize the hassle of voluntarily maintaining 
> bugzilla by using one of those.  Oh, by the way, X+3 is our next 
> long-term stable release, so you'll be able to get support for it for a 
> couple years."

As long as the long-term releases are centrally decided rather than at 
the whim of a "branch owner", that would be OK.

Perhaps we could number the releases in such a way to make it clear 
which were long term. E.g. 3.0 is long term, 3.2, 3.4 are not, 4.0 is 
long term, ...

Gerv



More information about the developers mailing list