Make convert-ly -d only ever update on changed files

Make convert-ly -d only ever update on changed files

Previously, it updated unconditionally whenever a new stable version
came out, leading to merge conflicts.  When the final applied
conversion is to an unstable version and the following stable version
is not beyond the conversion target, the following stable version is
used.

Note that this rule does not make a factual difference for continuous
updates of a code base (the normal use case for
scripts/auxiliar/update-with-convert-ly.sh), but it makes a difference
for the conversion/import of code that may have fallen behind a lot
(like with the LSR import, or when converting archived files).

[Keith, 2013-11-25 06:37:35]

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.

[dak, 2013-11-25 07:57:50]

On 2013/11/25 06:37:35, Keith wrote:
> 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

The "dummy" convert-ly rule is actually dummy when used with -d: it is not
specially parsed or anything.  The update is instead triggered by the version
number of the last checked rule.  For that reason, a number of issues with
convert-ly rule for 2.19.0 have not been uploaded by me: they contain thousands
of gratuitous changes.

> 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?

Because that's the you have considered a rule beyond that.

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

Yes, that's the intent.

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

This basically comes into play only when importing stuff.  Note that stuff like
the LSR runs on stable versions, and that's basically what "ordinary" users
have.  In that case, _if_ a conversion happens, the version number in the file
will reflect a stable version, 2.12.0, 2.14.0, 2.16.0, 2.18.0: whatever is the
oldest stable version left unchanged by convert-ly.

[dak, 2013-11-25 19:52:10]

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

Searching through the mailing list archives at that time does not turn
up more than
<URL:http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00349.html>
which does not give any reason for the change.