Here's an update on the release plans. These are not cast in stone; if you have a thoughtful objection or suggestion, I'm willing to change things.
1) 2.13.34, "alpha test" has been released. 2) website has been switched over. At first glance, I think I can close issue 1244 now, but I want to double-check and wait for feedback. 3) after 1244 is done, there's only one remaning Critical issue; http://code.google.com/p/lilypond/issues/detail?id=1173 NB: I expect approximately 5 more regressions to be reported in the next week. Some of them might not be regressions in code that worked deliberately. Bug Squad (if you read -devel): add any regression as a Critical issue; if a programmer points out that it only worked by a fluke in the past and downgrades it to Medium, that's totally fine. That's how the system is supposed to work. :) 4) if a bunch of development has occurred but Critical issues remain, I'll release 2.13.35 as a "second alpha test". Repeat as necessary. 5) Once we have 0 Critical issues, I'll branch stable/2.14 from master, and make a "release candidate" from that. We now wait 2 weeks. Development can continue as usual on master. The translation meister can backport translation patches to stable/2.14 if he wants; other people leave it alone. 6) if a Critical issue is reported, the clock resets. Once we have a bugfix, that gets backported to stable/2.14. No other changes to stable/2.14 occur[*]. I make a second release candidate, and we go back to step 5. [*] I'm willing to be flexible on this point -- we might prefer to merge everything from master into stable/2.14, or cherry-pick minor bugfixes and doc changes, or whatever. But my initial impulse is not to allow any non-Critical bugfixes, because I am bloody sick of seeing the number 2.13 and any change could have side effects. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
