Re: Stable releases

[David Kastrup]

Carl Sorensen <address@hidden> 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