Re: Post-2.12 release plans

[Trevor Daniels]

Graham Percival wrote Monday, December 22, 2008 5:40 AM


> Once 2.12 is out and we've succeeded in setting up GUB3 on
> kainhofer, I'll become the Release Manager.  I have two ideas on
> how to change things:
>
> 1)  Move to a linux kernel type of releases: instead of having
> separate devel and stable branches, we just do everything in 2.12.
> In some ways, we've been doing this already; we haven't touched
> 2.10 in quite a while.
>
> 2)  Keep the distinction between stable and devel, but tie it to
> the input syntax, and allow for much faster releases.  In
> particular, there would be *no* convert-ly rules for 2.12.  New
> constructs would be fine, but any patches that would change
> existing syntax would be delayed until 2.13.

I'm not sure I go along with this.  The main point about the
stable even-numbered releases is that they are *stable*.  If 
"permitting new constructs" implies permitting new features and 
new code, then the release is potentially unstable.  I would prefer
changes in even-numbered releases to be limited to bug-fixing, and
even bug-fixes with significant code changes should be deferred to
a development release.   

> In the past we've avoided this kind of policy since it slows down
> development, but my proposal is to have /much/ faster development
> cycles.  Maybe something like 3 months of 2.12 releases, then 2
> months of 2.13 releases (including the delayed syntax changes),
> and then 2.14.  Then we'd repeat it again.

I agree stable releases should be made more frequently.  But I
don't see why spinning off a stable release impedes the development
process.  Can't the stable release be contained in a separate branch?
Or am I missing something?

> Cheers,
> - Graham

Trevor