Re: Could we do something to promote convert-ly?

[Valentin Petzel]

Hello Jean,

2.23 would only provide such an alias if an earlier version was specified. So a 
user can only keep using ParenthesisItem when explicitely stating that he'd be 
using an old version of the language.

Thus this would also not at all affect recent files.

The problem is that Lilypond does reject too new files, but not old files. This 
means that Lilypond assumes it can understand older language versions when it 
basically has no clue about it. So basically Lilypond makes a promise it cannot 
keep.

A different approach would be issuing a warning when compiling an old version. 
This would make clear that Lilypond does in fact not offer any support for 
files written in previous versions.

Valentin

09.02.2022 15:46:36 Jean Abou Samra <jean@abou-samra.fr>:

>> Le 09/02/2022 15:15, Valentin Petzel <valentin@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