Ok, after looking at the current situation and the current patches in review/countdown, I've decided that I'll fork off the stable release branch 2.18 after the current batch in countdown is in master. After that point of time, I'll only cherry-pick patches into the stable branch after having convinces myself that they are no trouble.
What does this imply for other branches? a) master branch The master branch should not receive merge nuisances. Those are, for example, large reformattings and other cosmetic changes. Also code refactoring with non-trivial extent should be postponed. No syntax changes requiring convert-ly rules should be performed since we want to be able to release multiple 2.17 releases while 2.18.0 has not yet been released, without messing up the order of convert-ly changes. Documentation changes should restrict themselves to corrections, and those should be done _fast_ so that translators have a chance to catch up. b) translation branch The translation branch will stop getting merged with master. Some documentation changes from master might get cherry-picked into translation (I will do that myself), and translation will get merged into the stable branch periodically, also by myself. Translators are urged to start bringing the translation branch into releasable state _now_. There will only be few changes from now on until the release of 2.18. We might get one or two unstable releases before 2.18 gets out. Personally, I'd prefer if they used numbering starting with 2.17.95 to make it very clear to people that we are in the final stages of shaping 2.18 up and that any release-relevant testing, reports, and fixes have to come in _fast_. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
