Werner LEMBERG <w...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel