I'm fine with this, but then we would probably want to run convert-ly without the '-d' option on Documentation/snippets, upon creation of version 2.18.0.
Maybe there is a way to get the behavior of "round-up-to stable version" triggered by the (usually dummy) convert-ly rule for that version. I can only think of kludgy ways right now https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py File scripts/convert-ly.py (left): https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#oldcode295 scripts/convert-ly.py:295: # check the y in x.y.z (minor version number) This did cause me confusion recently, while preparing the keySignature name-change that I had postponed for the 2.19.x branch. I knew about the mechanism to update to a stable label using a dummy-rule mechanism in convertrules.py, but this hidden mechanism surprised me. Why, I thought, does it know about 2.18.0 when that version does not exist? https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#newcode306 scripts/convert-ly.py:306: last = next_stable The old code was there so that the \version ".." is updated for a new stable version <http://codereview.appspot.com/2642041/#msg3> It looks like the new code does not perform this function. It takes some patience to understand what this does, either by reading the doc-string or the code, because it is a sophisticated behavior, and I do not understand its purpose or motivation. https://codereview.appspot.com/31830043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
