[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stable release.
From: |
Keith OHara |
Subject: |
Re: Stable release. |
Date: |
Mon, 25 Jun 2012 18:46:55 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
David Kastrup <dak <at> gnu.org> writes:
> It is a reasonably safe bet that we won't have a stable release 2.16 in
> the next two months given our current release policies and policy change
> policies and their past effects on release candidates.
I'll take the other side of that bet.
LilyPond seems in a more stable condition than at the 2.14 release. I think it
is time for 2.16.
The release blocking issues could be fixed with minor reverts.
2524: Enhancement: run `make po-replace` as part of release
The difficulty is that po-replace requires a copy from build-directory to top
source-directory (even after makefile improvements) so the build checklist is
not a simple copy-paste to the shell. The enhancement was not critical;
adopting it without a shell script is the critical problem.
We can revert the commit that adds `make po-replace` on the release checklist
in the Contributors' Guide. Jean-Charles seems willing to po-replace the old
way for a bit longer.
2604: Maintenance: add CG instruction to define LILYPOND_BUILD_DIR
Then the shell commands for 2524 can be copied from CG into a shell.
An /extremely/ sensible path to address 2524, but not the only path. So 2604
need not be critical. I have some hesitation to do this sensible step myself,
because I don't use out-of-tree builds.
2623: Critical: an earlier enhancement hit a Windows difficulty.
One choice for path separator also, sometimes, acts as an escape character
lilypond-book -I ".\"
The earlier commit's author will probably fix this soon if he is in town. If
not, in three days I will revert the troublesome commit, and help him test a
repaired commit later.
> As a sort of emergency measure, I would consider it sensible if we did a
> source-only release of 2.14.3 or, if you want to, 2.14.2a, the same as
> 2.14.2 plus cherry-picked compilation fixes. Namely just what it takes
> to get 2.14.2 through the current compilers.
Very sensible. Distributions from source should have the option to include a
recent (especially the most recent) stable release without compiler gymnastics.