Timed releases, versions, etc... [was Re: Freeze proto.h?]

[Jeremy Allison]

On Mon, Apr 21, 2008 at 09:46:16AM -0500, Gerald (Jerry) Carter wrote:
> This warrants a separate discussion of how to do time releases.
> Might as well start it now.
> 
> I spoke with Karolin about this some last week and she agreed
> that a 6 month release cycle is a good starting point.  We
> also had some other ideas which I'll describe here.

Ok, 6 months sounds about right to me.

> Here is my proposal that I'll put on the table:
> 
>     Once a new release cycle is done, that version goes
>     straight to bug fix mode and the next release cycle gets
>     a new minor release number.
> 
> So for example, Assume 3.2.0 is released in the next 30 days.
> The 3.2 releases are immediately in maintenance mode meaning
> we can fix all the regressions and bugs we like.  But no new
> features.  The next 6 month cycle clock starts ticking and
> that becomes v3.3.  I believe this will be much appreciated
> by users and vendors a like as it promotes more predictability
> and prevents onerous changes that would destabilize the current
> production releases.  The only reason we have not done this
> in the past is lack of resources and a fears of vendors delaying
> picking up new releases.  But the current system probably
> makes it too confusing to know what is a "good release".
> 
> Karolin will have the job of setting dates and we have to
> stick to them.
> 
> 
> PS:  Note that the 3.x series can be infinitely extended so
> there are no future conflicts with a v4.0 release.

That's a lot of discipline needed to make that work.
It's a lot of effort to keep a tree in maintainence
mode as well as a new tree.... Hmmm. But I guess we 
already do that with 3.0.x at the moment.

Jeremy.