On Sun, Nov 28, 2010 at 11:33 PM, Graham Percival <[email protected]> wrote: > > 2) release 2.14 ASAP with no critical flaws, but with some kind of > code freeze. > Many software projects implement a "freeze" before a release -- > when the project is "frozen", this means that no changes are > allowed, unless they have a very good reason why they absolutely > must be changed before the next release. With git, there's no > technical reason why we might want to freeze anything (I could > just branch a stable/2.14, and just cherry-pick individual commits > to apply to this branch). However, there are social reasons for a > freeze. We (implicitly) have a freeze on policy decisions, to > avoid spending time on those instead of release-critical work. > We could add a freeze on patches and code, to avoid spending > time on those instead of release-critical work.
I like the idea of branching master to stable/2.14 and cherry-picking fixes for critical issues (and compile/build fixes for Guile 1.9, etc). Merging translations work from lilypond/translation to stable/2.14 would be just as easy. This would allow work in master to proceed uninterrupted. I also think it would be useful to have two code freezes on stable/2.14: one for code/docs, and one for translations (right before the release). Thanks, Patrick _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
