On 11 mars 2013, at 16:32, "Trevor Daniels" <t.dani...@treda.co.uk> wrote:
> > David Kastrup wrote Sunday, March 10, 2013 5:32 PM > >> 2.16 is growing old. >> >> So I want to see 2.18 soon. That means we need to stabilize work that >> has already been done and cut down on experiments in the master branch. > > Agreed. > >> Stabilizing means more or less accepting the current feature set, and >> making sure it works as intended, is a useful combination of things, >> does not offer interfaces which are sure not to survive into the next >> stable version, and most of all, is properly documented to the user. > > Once the decision to stabilise is taken, further work on new features > should take place in branches. It doesn't have to stop. That's how the > skyline code was developed before it was merged into 2.17 and that > procedure worked well. > >> At any rate, I'd like to aim for 2.18 at about the end of May, and >> getting into serious freeze at the end of April. A focus on bug fixes, >> in particular bugs introduced in the 2.17 development cycle, should take >> priority. Fixing long-standing bugs hard to address should likely be >> left for early 2.19 and/or be done in a branch. > > Why not freeze sooner? The current state is sufficiently different from > 2.16 to justify a new stable. > > I'd also like to propose we adopt the same controls as we did for 2.16, > if David is willing, since that also worked well. That way we'll get a > clear plan - what must be fixed, what must be documented, what is > permitted to go into master, etc. Otherwise we'll simply disagree for > ever. > I like the idea of freezing right away and releasing after two weeks of critical-bug-free lily. What is difficult for me is setting the freeze down the line without being able to wrap up work first. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
