----- Original Message -----
From: "David Kastrup" <d...@gnu.org>
To: <lilypond-devel@gnu.org>
Sent: Saturday, September 28, 2013 1:25 PM
Subject: LSR imports and version numbers?
Hi,
I've seen the last LSR import do nothing but bump the version number on
a large number of files from 2.17.25 to 2.15.27. Now that's consistent
with the current documentation on convert-ly which states:
The following options can be given:
-d,--diff-version-update
increase the \version string only if the file has actually been
changed. Without this option (or when any conversion has changed the
file), the version header reflects the last considered conversion
rule.
Now this documentation was written by myself after reverse-engineering
the code. But frankly, it does not make sense. If the version is not
even touched unless the file is changed, then it does not make sense to
update the version number to the last _considered_ conversion rather
than the last version actually making a difference.
_Without_ using -d, it's ok that the version header is bumped across all
conversions that will not be considered in future. But it does not make
sense to do that when the _trigger_ for an update is an actually
happening conversion.
Can we agree on that? Because if we can, it will mean that LSR imports
will not keep increasing version numbers higher than necessary, I think.
--
David Kastrup
The bumping of version numbers is a pain for me, too - it makes it tedious
to check what makelsr has _really_ done.
I think we should have 2 alternatives: a) bump the version if the file is
updated, and not if it hasn't or b) bump to the current version regardless.
We should use a) with makelsr.
There is a question in my mind as to what a) should bump the version to: i)
current version; or ii) version that the update related to. Simplest is
probably i).
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel