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.