Release timing

[Christopher Hicks]

On Sun, 23 Jan 2005, Gervase Markham wrote:
> 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?

Given how long 2.18 took to get out going to fixed freeze dates seems like 
a good idea to me.

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

You're right, lets follow the crowd and do what everybody else is doing. 
I'll start boning up on PHP now.

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

The developers need not care if its the same calendar date, but they will 
find it easier to hold in their head if it is.  You seem to agree that the 
developers care more about the freeze date than the users care about the 
release date.  So, then why not make the freeze dates easy to remember?

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

A maintenance branch owner would be told whether they had a short-lived 
branch or a long-lived branch on their hands when they took it.

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

That would lead to every othe release being a long term release and I 
don't think that would be good given that part of the goal was to limit 
the number of currently long term releases.  On the other hand it would be 
cool if the "summer" bugzilla releases were the long lived ones and the 
"winter" releases were the short lived ones.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)