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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel