LilyPond 2.20 release process

[David Kastrup]

In order to properly wrap up my maintainership of LilyPond, I would like
to make sure that LilyPond 2.20 is released in an orderly manner.

Work that does not appear to make sense to include in 2.20.1:

a) Guile 2.0 support in release-quality manner and enabled by default.
However, in order to incentivize further participation of volunteers,
I would like to urge the people having recently worked on Guile 2.0
support to merge their work into the main line, if necessary guarded by
suitable #ifdef (in C++) and the corresponding guards (in Scheme).

b) default directory structures for enabling custom additions and work
processes along the lines of openlilylib.  I would urge the openlilylib
crew to assess their current work and see whether they consider any
parts suitably stable and robust and useful to include in the next
release.

c) thorough reorganizations of code, like trying to do rationals inside
of Guile rather than separately.  I may try something along that line
eventually but there is no time line for it.

What is definitely desired, however, is all of the following:

Check any added features (that the authors knew to have implemented but
not suitably documented) and see that we have regtests for them and
reasonably good documentation.

Have stable font support that works reliably on all platforms which we
intend to support natively or with binaries.

Figure out a strategy how to deal with distributions dropping support of
Guile-1.8.  It may be necessary to contact appropriate maintainers and
previous contributors, and it may even be necessary to fork and maintain
Guile-1.8 for an indefinite time as long as Guile-2.x+ cannot be turned
into a satisfactory extension system due to disinterest of the Guile
maintainers and/or the shortcomings in areas making it work as an
extension language in the first place and/or lack of rearchitecting
LilyPond where Guile's focus no longer matches the technical
requirements of us.

By far the least work (while Guile-2.x is not a reasonable option) would
seem to be in the area of supporting a continued smooth inclusion of
Guile-1.8 in distributions for a while.  This is something that Guile
developers do not like: it might be used as an incentive to actually get
any of them to look at the problems LilyPond provides.

Naturally, if one can smoothly compile LilyPond for both Guile-1.8 and
Guile-2.0 (requiring readily available development environments for
both, again making it desirable for distributions to continue including
them for a while), the comparison of their performance and issues will
be reproducible for anyone with an interest.  We _really_ want this kind
of showroom in order to advertise the current problems and make Guile
developers care.

So I really would urge the Guile-2 warriors to fold their work into the
mainline.  We want it distributed by default, but probably with a
stronger warning against --enable-guilev2 (or what it was called),
bluntly mentioning the speed of LilyPond dropping to a third.

---------------

So the usual proposition would be a feature freeze first to give people
time to focus exclusively on release-readiness.  After the main flurry
of release-level commits has abated mostly, the release branch will be
forked.

Development work can then pick up again on the master branch.
Documentation changes relevant for the release branch may get picked
into the release branch, so major documentation reorganizations and
other disruptive changes or refactorings making it hard to cherry-pick
bug fixes and last minute documentation changes from master into the
release branch should be done in developer branches instead.

At any rate, translators should focus on translating the release branch
at this point of time.

Bug fixes and documentation fixes occuring in master will be
cherry-picked into the release branch as appropriate in a continuing
way.

Before release is imminent, all translations should at least try to
update the Changes files, and we would want a boilerplate text to
include in the main documentation web links to point people to the
current original (or uptodate translations) for all translations that
have not kept up.  It might also be appropriate to include a warning in
every translation that states the approximate documented version if it
isn't the current one.

>From the time of the release branch fork to the actual release
(approximately 1 month), it may make sense to refrain from releasing any
developer release in order not to confuse the versioning and to keep
people focused on the release.  That's not an iron rule but it makes
some sense, and in order to avoid double work for the release managers,
we might be putting out prereleases only instead of developer releases.

That's the rough sketch of how things mostly worked out in the past, and
how I see this taking place this time (anyone want to preserve this text
or a summary of its structure without the stuff pertinent only to this
release for the Contributors' Guide?  Seems like it might make a good
template for whoever will make the next stable release).

Assuming Graham is on board with this plan, I'd like to get the release
part of this achieved until mid-to-end February.  It would have been
nice if it made it into major distributions releasing end of April, but
I don't think we'll meet those deadlines and it will likely be much more
pressing to do the requisite lobbying work to get LilyPond included at
all: the Guile-1.8 dependency is not fixable for 2.20 either if people
are supposed to use LilyPond for serious work.

LilyPond has improved in technical respects during my tenure (and even
though I sizzled out on Guile-2.0 work, a lot of prerequisites for its
code base, both Scheme and C++, have been worked out that were necessary
for the transition).  But its current situation in the distribution
landscape and the Guile universe is lopsided.  I really hope that my
successor(s) manage to get this straightened out eventually as it is
certainly vital for LilyPond's future.

-- 
David Kastrup