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