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
signature.asc
Description: This is a digitally signed message part
