2008/12/22 Graham Percival <[email protected]>:
> 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:

Good to see you're still involved, Mr
"I'm-leavin'-soon-anyway-so-just-pretend-I'm-not-here" :-)

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

Hm, let's not be too strict in advance. No "major" breakage in 2.12 is
already a sensible goal; no syntax change at all... well, there's
always the possibility that we have to correct some inconsistency we
may have missed until now, or whatever.

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

Actually, not having to backport anything from 2.13 to 2.12 might also
make development move faster.

> Yes, this would mean that some patches would be delayed a few
> months, but with git it's easier to test them in separate
> branches.  We'd also be flexible about when to start 2.13 -- if
> there was a great new feature that required changing the existing
> syntax, we could start .13 earlier than 3 months.  Conversely, if
> all development is simply adding new features or fixing bugs, we
> don't start .13 until later.

Does this mean you do not want to make any difference between odd and
even versions?

Cheers,
Valentin


_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to