|
From: | Phil Holmes |
Subject: | Re: Releases 2.17.6 and 2.16.1 |
Date: | Sat, 3 Nov 2012 16:29:53 -0000 |
To: <address@hidden> Sent: Saturday, November 03, 2012 4:07 PM Subject: Releases 2.17.6 and 2.16.1
Hi, I have just been merging translation into stable (after checking compilation, tests, and documentation). I am not totally happy with 2.16.1: we still have non-convergence on the line-count stuff (which I will leave in its current state), and it is conceivable that there is some regression concerning #{ \include ... #}. In particular with regard to the latter, I am tempted to either cherry-pick some stuff that has seen no serious exposure (issue 2939 <http://code.google.com/p/lilypond/issues/detail?id=2939> is still in countdown), or alternatively revert some performance-related patches of mine that have been picked post-2.16.0. I'll have to do some testing to figure out the exact scope of the problem and then make a decision. On front of the unstable release, we are having several reviews in countdown with 2.17.6 syntax, and I think we should roll out 2.17.6 as soon as possible to avoid things getting too complicated on the convert-ly front. -- David Kastrup
I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I know how to fix this manually and have done so, so it's ready for upload. I will do the upload when we're not using my internet connection for anything else... (This evening or tonight). So 2.17.6 should be visible during tomorrow.
For anyone interested in why Gub was failing, it seems it's to do with using a commitish as a signature of showing whether make test, etc., should be re-run. Unfortunately the function that checked the cached signature was looking in the wrong place. I've just pushed a commit to gperciva/gub that will likely fix this - although this is somewhat "by inspection" so if anyone knows more of the internals of gub and can comment, I'd be happy.
--Phil Holmes
[Prev in Thread] | Current Thread | [Next in Thread] |