Hi,
after we got 2.17.95 out the door with some minor lacerations, I had a
double take and, well, I got a few things confused.
Here is our current situation:
a stable/2.18 branch has been tied off. Afterwards, several other
changes were committed to master and 2.17.95 was released from master.
How is that supposed to lead to well-tested stable branch? Excellent
question.
What should have been done after tying off the stable/2.18 release
branch would have been releasing 2.17.95 from the stable/2.18 release
branch, and calling master the upcoming 2.19.0.
So how do we proceed from here? My suggestion is to do 2.17.96
"properly" from the stable/2.18 branch. Looking through the difference
between the current mark of stable/2.18 and release/2.19.95-1, there are
just two non-trivial commits that are _not_ fixing a release-critical
problem.
Those are basically:
commit 0b032b61be1224b2cce061df60aa89ea5aa89c07
Author: Mike Solomon <m...@mikesolomon.org>
Date: Thu Oct 31 08:40:23 2013 +0100
Adds ly:generic-bound-extent function.
This allows for spanner functions written in Scheme to use bound
extents instead of the full extents of their bounds.
Adds a regtest to show this at work with BendAfter.
Note that this can likely be replaced in the future with horizontal
skylines.
commit 12e6948fe2fa0c73103748fd815a7c93fdc3677e
Author: Thomas Morley <thomasmorle...@gmail.com>
Date: Wed Oct 16 21:39:57 2013 +0200
format-metronome-mark and metronome-markup don't support styles other than
default
issue 3096
- introducing 'styled-metronome-markup' with the (currently quite
theoretical) possibility to use another font here. For now
the font-argument is used only to make
\override MetronomeMark #'font-name = ...
possible.
- adding 'flag-style to define-grob-properties.scm, the
MetronomeMark-properties in define-grobs.scm and in text-interface.cc
- adding a regtest for different 'metronomeMarkFormatter'.
It's now possible to override MetronomeMark with 'style, 'flag-style and
'font-name to customize the appearance.
That's all. It would be possible to cherry-pick everything except those
two commits, but there are also merge commits that have happened since
then, and merge commits are quite troublesome when cherry-picking. So
instead I'll bump stable/2.18 to the current state and then revert both
commits. The commit from Thomas since that is a feature commit, the
feature is not going to get well-tested just after introduction, and the
description "currently quite theoretical possibility" suggests that it
would make sense to give the functionality and its interfaces time to
mature and get documented (and translated) before nailing it down in a
stable release.
The commit by Mike, in contrast, does not significantly affect user
interfaces and is intended as a bugfix. It has gone out in the course
of 2.17.95, so we have a chance get relevant feedback about any problems
with it. However, it only affects bendAfter via bend::print, so it is
quite limited in scope, the problem has been there for a long time, and
there would not be much testing to be expected from 2.17.95. So I'm
more comfortable reverting it as well.
Reverting, as opposed to cherry-picking, has the disadvantage that if
one ever merges master and stable/2.18 again, the revert will be
considered the relevant change to keep. We are not planning to merge
them again (I think), but one has to watch what one does when juggling
with the translation branch. So I'll try keeping care of that until
translation moves back to master. I don't guarantee I won't mess this
up, but at least I'm pretty confident that I can repair whatever mess
I'll create.
Yeah, so sorry for making the split-off of the stable branch more of a
rocky ride than necessary. After bringing the branches in the mentioned
constellation, I'll straighten up the versioning, with stable/2.18
tentatively leading towards version 2.17.96 next, and master leading
towards 2.19.0.
Any objections or additional input, particularly from Thomas and Mike?
If not, I'll probably straighten things out tomorrow at the latest.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
