Current state of release planning.

[David Kastrup]

Whoever has watched the repository closely will have noticed that there
is now a branch stable/2.16 corresponding to the last release 2.15.95.
The next release from that branch according to VERSION will be 2.15.96,
but it might also be 2.16.0.

VERSION in staging announces the next release to be 2.17.0 as the next
unstable release.

Since it would be awkward (but not impossible) if 2.17.0 would be
released before 2.16.0, any patches now entering in master will not have
seen exposure in a development release before 2.16.0 is tentatively
released.  As a result, only very few things have a chance of entering
the stable branch right now.  Any regression fix needs to be "dead
obvious" and thoroughly tested.  Any change in functionality must not
change previously valid programs (that's not just for 2.16.0 but the
whole branch).

Issue 2737 <URL:http://code.google.com/p/lilypond/issues/detail?id=2737>
Patch: Allow all papersizes to be specified with a trailing "portrait"
or "landscape" string.

in its current state meets the compatibility criterion, but is of
borderline complexity and will consequently not make 2.16.0.

Issue 2583 <URL:http://code.google.com/p/lilypond/issues/detail?id=2583>
Hairpins with to-barline=##f do not close at the end of a staff

is a regression fix, but with non-trivial (although simple) code and
consequences, and fixing a non-catastrophic condition.  It will not make
2.16.0.

As one result of this decision to clamp down strictly on the kind of
changes still admitted into 2.16, we will get a release 2.16.0
reasonably soon, and hopefully before 2.17.0.

There will be several changes (the listed ones are rather certain
candidate) that will, after sufficient exposure in 2.17, be considered
fit for 2.16.  Probably a month after 2.16.0, there will be a release of
2.16.1.  I expect the release schedule for 2.16 to drop off after that
as regression fixes and must-haves become less frequent.

Documentation improvements are still admissable, documentation rewrites
not necessarily as we want to avoid significant changes between the
English documentation and reasonably well-maintained translations.  I
have no clear view regarding finalizing of the translations.

-- 
David Kastrup