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.
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).
It's just fortunate that LilyPond is sufficiently backward compatible
for basic code that version problems don't often crop up. convert-ly
will be there if something actually goes wrong, but this remains an
annoyance for people concerned with precision.
On 7/1/2023 12:09 PM, Jean Abou Samra wrote:
Le samedi 01 juillet 2023 à 11:30 -0700, Curt McDowell a écrit :
I tend not to use convert-ly because I feel upgrading a file version
would unfairly force anyone who wants to compile my music to upgrade
their LilyPond installation. Upgrading might not be straightforward when
using a standard distro, and I'd hate for someone to risk destabilizing
their working environment on my account.
lilypond.org distributes static self-contained binaries of LilyPond
that can just be unpacked in whatever directory and run from there
without being installed in some way, so the risk of destabilizing the
environment is exactly zero.
