Carl Sorensen <c_soren...@byu.edu> writes: > So, with this idea in mind, I'd like to kick off a discussion about > the next stable release. Assuming that we can fix all the critical > issues (I think that's possible, but may be a month out or so), what > else should we plan to have part of the next stable? Is there > something being worked on and almost there such that we should wait > for a stable release until it's implemented? Is there something > that's so poorly implemented it should be eliminated from a stable > release?
We have undead parsed objects. That points to inconsistent data structures. We have had a large influx of new functionality (much in the area of spacing) that has seen no significant amount of testing and that has displayed some problems. The state of translations is not well-known to me: I am pretty sure that there must be several translations seriously lagging behind. Personally, I would like to get the parser changes moved to a more consistent base point, but without anybody pitching in with help on the outstanding engraver issues in <URL:http://code.google.com/p/lilypond/issues/detail?id=2070> (in particular comment #16 and #17), a satisfactorily stable foundation with not more than the technically necessary amount of incompatibility seems out of range. So the options are doing a less smooth job with worse compatibility, or stopping dead in one's tracks: attempts to continue the parser work without getting this one into place have ended in too much code juggling to pull off before concentration breaks, and that is not a state we want to have code in, anyway. Due to the many code changes since the last release, we would need a beta test candidate declared and seriously encourage users (rather than developers) to test and report, with a focus on documents remaining workable, and documentation in all languages being up to par. Whether we need to branch off a release branch to keep master a playground for the sprightlier among the developers is a different question. We might instead encourage them to retain their local work in their private repositories until the hot release phase is through. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
