lilypond-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]