Hello Paolo, > Given that, as Valentin noted, a new property has been introduced that > allows code to be compiled with the old function, what is the point of > exposing it to the user if it then corresponds to an API break? > If it had been treated as a deprecated property I could have simply ignored > the warning.
the new property is there to allow for convert-ly to automatically make old things work. I just do not fully understand why it is necessary and could not simply be handled by adding a conversion function, e.g. turing something like `...proportionalNotationDuration = ...` to `...proportionalNotationDuration = \moment-main-part ...` or whatever. Regarding API breaks: To some extent API breaks are of course something you should not do lightly, as an API essentially promises that you can rely on a certain behaviour. As far as I know Lilypond tries to keep API consistent at least within a major version, so something like this should not happen between say 2.24.3 and 2.24.4. I understand that for you developing a product tied closely to Lilypond not having a stable API is annoying, but please keep in mind that 2.25 is the development release. You can and should not develop something against it and assume that things will keep working. I think in this particular case though it would have sufficed to run convert-ly on the old code. But Lilypond does not do this because the devs want to annoy you. And if you have reasonable ideas how such API changes could be communicated better I am sure people would love to hear them and if feasible incorporate them. Cheers, Valentin
signature.asc
Description: This is a digitally signed message part.
