[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Continuing towards 2.18
Continuing towards 2.18
Tue, 05 Nov 2013 09:23:40 +0100
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
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
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
Those are basically:
Author: Mike Solomon <address@hidden>
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
Author: Thomas Morley <address@hidden>
Date: Wed Oct 16 21:39:57 2013 +0200
format-metronome-mark and metronome-markup don't support styles other than
- 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 = ...
- 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
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
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
Any objections or additional input, particularly from Thomas and Mike?
If not, I'll probably straighten things out tomorrow at the latest.
- Continuing towards 2.18,
David Kastrup <=