Release timing

[Gervase Markham]

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