> Le 09/02/2022 15:15, Valentin Petzel <valen...@petzel.at> a écrit : > > > Hello Jean, hello everyone, > > this does sound like a good idea. But what I've been thinking about for a > while is: For many incompabilities Lilypond could very well know how to > handle things. With things like music functions or grobs changing names we > could simply have a set of includes to make the previous version compatible > with the current one. This could then have compatibility functions, we could > try something to alias Grob names and properties and stuff. Then Lilypond > 2.23.6 could automatically include the file for 23.5, for 23.4 and so on > until we are at the specified version upon encountering a version string. > While this cannot handle every possible change in format (it is not like > convert-ly could) it would be able to handle the most common problems with > older language versions automatically and non-destructively. > > And with things that cannot be easily wrapped to the new functionality we > could throw an error, telling the user that something requires manual > intervention. > > Just some thoughts I had for some time.
This means more code to write, test and maintain, code that accumulates in the repository and is never replaced, growing complexity over time. It also means that I can read a question on lilypond-user with ParenthesesItem in \version "2.23.6" and be surprised not to find ParenthesesItem in the Internals Reference, and similar confusion. Furthermore it means that a user can continue to use the name ParenthesesItem and think that parentheses never got supported on spanners, or not think about looking in the spanner-interface for properties that can be overridden on parentheses enclosing a hairpin -- there is normally a good reason to rename something. On the other hand, it sound like this can mostly help with renamings, which are exactly the type of change that convert-ly is good at handling reliably. So where would this bring an advantage? That's the part I'm not seeing clearly. Best, Jean
