Le dimanche 02 juillet 2023 à 23:25 -0700, Curt McDowell a écrit :
>  
> I don't think it's tenable to expect anyone to keep a separate version of
> LilyPond for each unique \version called for by all the scores in their
> library. In the current system, that would be the only way to guarantee
> correct and consistent output.


The recommended approach is not to keep zillions of versions, but to upgrade all
your scores once a stable release is out (2.24 being the latest), using convert-
ly. Stable releases are relatively infrequent (the two latest ones took a year
and a half each).

> I'd hesitate to call the LilyPond version system "lazy", as backward
> compatibility can be complex especially with subjective fuzzy output
> correctness, but pretty much every other programming language or application
> file format manages to deal with it. When they reach a breaking point after a
> decade (maybe something like going from Guile 1.8 to 2.2), they increment the
> major version number and only then do users have to maintain multiple versions
> or modernize a lot of code (e.g. Python 2.7 to 3).

Python is not a bad point of comparison, since it's a very dynamic language,
similar to LilyPond. And you will find that backwards compatibility is a major
common complaint against the language, and not just because of Python 3. I think
it has been getting better lately, but at the price of a lot of effort put into
backwards compatibility.

All the best,
Jean

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to