Le 08/02/2022 à 21:29, David Kastrup a écrit :
David Kastrup <d...@gnu.org> writes:
Jean Abou Samra <j...@abou-samra.fr> writes:
Folks,
I am getting tired at the number of questions of the type
"Why doesn't this work anymore?" which can be answered by
"Just Run convert-ly! (TM)". I suspect that the effort we
put in crafting convert-ly rules is not paying in perceived
backwards compatibility as users don't think about running
convert-ly, or perhaps don't even know about it. Could we
do something to change this?
Some ideas:
- Mention it in release announcements,
- Mention it in the Changes document,
- When the score produces an error and the \version
statement is for a different minor version number,
print a warning ("compilation failed and \version
statement is outdated, did you update syntax with
convert-ly?" or something like that).
Thoughts?
Different major number. Possibly also odd major number and different
minor number, but I guess stable releases are done frequently enough
these days that it's unlikely a distribution will package an unstable
one.
An extra bit of work would be maintaining a list of regexps since the
last major version that would trigger the message, with the message
always being triggered for a major version change. If we want to avoid
calling a Python interpreter, the regexps should likely be Guile
regexps.
Well, lexer.ll contains
Lilypond_version oldest_version ("2.7.38");
bool
is_valid_version (string s)
{
...
if (ver < oldest_version)
{
non_fatal_error (_f ("file too old: %s (oldest supported: %s)",
ver.to_string (), oldest_version.to_string ()));
non_fatal_error (_ ("consider updating the input with the
convert-ly script"));
return false;
}
...
}
where oldest_version has not been updated in 15 years.
What you suggest would be nice in theory but I am wary
of maintenance.
