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
> 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, ...
More information about the developers