Re: 2.14 release, or GOP now (part 2)

[Patrick McCarty]

On Sun, Nov 28, 2010 at 11:33 PM, Graham Percival
<address@hidden> 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