Re: Reasoning behind convert-ly rule for stable update?

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> Does anybody know _why_ convert-ly updates at least to the last
>> stable version number even if nothing else has been changed?
>
> Looks like a bad idea, indeed.
>
>> Or make \version accept a range?
>> 
>> \version "2.16.0 - 2.17.28"
>> 
>> Then LilyPond just needs to check the first number, and convert-ly
>> just deals with the second number as long as it does not need to add
>> another conversion.
>
> I don't like this.  \version should stay unmodified if nothing gets
> changed, and I favor a change in convert-ly accordingly.
>
> However, I can imagine that, completely independent from convert-ly,
> another script adds something like
>
>   % tested with version "2.17.95"

That's nice and all, but irrelevant to the problem of reducing the
amount of work convert-ly has to do on unchanged files.  Currently
convert-ly checks about 30 rules or so at the end of an unstable release
cycle.  This would easily grow into several hundreds if we don't leave
any indication what kind of rules _have_ already been applied without
effect.

I'm not sure that's actually a problem: at the current point of time, by
far the bulk of update-with-convert-ly.sh's runtime is spent running
"make all".

And it's probably also ok to restart with a clean state for LilyPond's
core documentation files, and its code files.  But for the LSR snippets
and the example files and the regression tests, it seems somewhat
excessive to update.

Now the idea of "add a comment" is not really useful when the aim is to
avoid unnecessary merge conflicts.  If we don't want merge conflicts
from the main \version, we don't want them from a comment either.

Taking a look at our current Documentation/snippets, we have the
following statistics:

git grep -h '\\version' Documentation/snippets|sort -n|uniq -c
    140 \version "2.16.0"
     26 \version "2.17.11"
      2 \version "2.17.13"
      2 \version "2.17.14"
      9 \version "2.17.15"
      5 \version "2.17.18"
      2 \version "2.17.23"
      4 \version "2.17.24"
      2 \version "2.17.25"
      8 \version "2.17.27"
      4 \version "2.17.28"
      1 \version "2.17.29"
     34 \version "2.17.30"
      2 \version "2.17.5"
    162 \version "2.17.6"
      4 \version "2.17.7"

So in this cycle, only about a third of the files stayed at 2.16.0.  So
the average "conversion chain length" will not actually reach even two
stable versions.  Of course, it is not random which files get hit: the
really short and simple ones are more likely to stick around unchanged
for longer.  But those are also less costly.

The regression tests are quite selective: here we have 718 of 1185 that
are at 2.16.0, so about 60%.  But that still does not make for much more
than a mean delay of 3 stable versions before update.

So I lean towards just ripping the respective code out from convert-ly.
I _think_ we have options that allow to simulate the update to a
particular version if one really wants to.

Of course, this will likely make the LSR import slower, too.  But I
think it can't hold a candle towards the "is this safe?" checks, either.

-- 
David Kastrup