[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to submit a feature request (issue)
From: |
Jean Abou Samra |
Subject: |
Re: How to submit a feature request (issue) |
Date: |
Mon, 03 Jul 2023 08:54:16 +0200 |
User-agent: |
Evolution 3.48.3 (3.48.3-1.fc38) |
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