Release timing

[Stuart Donaldson]

Trying to reset on some arbitrary calendar basis, based on the last 
freeze, would appear to open Bugzilla up to an abnormally long 
stabilization effort, causing problems.

What about the idea of "Freezing" 4 months after a release, allowing for 
an estimated 2 month stabilization time, give or take some arbitrarily 
long time like Bugzilla just experienced.  During the freeze, the trunk 
is frozen, no new development branch is created, to encourage people to 
work on stabilization efforts. Basically, By not resetting the clock 
until the release goes out, you solve the problem of having releases 
stacking up, and you guarantee a suitable window for feature enhancement.

I thought I saw this suggested, and apparently hadn't been following 
this thread closely enough, or missed why this wouldn't work.

Thoughts?

-Stuart-



David Miller wrote:

> Gervase Markham wrote:
>
>> "Remind me why delivering sooner than six months after the release we 
>> just did is a good thing?"
>>
>> 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.
>
>
> But Nick's idea didn't say that.
>
> We advertise to everyone "we're releasing every 6 months".
>
> We make those dates be May 15 and November 15 every year.
>
> In order to meet those release dates, we freeze 2 months in advance, 
> i.e March 15 and September 15.
>
> If things happen to get cleaned up faster than 2 months, then we 
> release early.
>
> So the releases could, in theory, range anywhere from 4 to 8 months 
> apart from each other, but will very likely stay pretty close to 6 
> months anyway.
>