Reinhold Kainhofer <[email protected]> writes: > What makes lilypond unfeasiable as a storage format is that its > internals change so often. In particular, we currently have the > viewpoint that changes to \overrides are internals, so we don't have > to care about compatibility. In other words: We care only about > trivial scores, where absolutely no overrides are required. In > reality, however, I have not encountered a single score without any > overrides for layout purposes. > Since we don't guarantee anything about \override, one can never be > sure that a huge score you are writing today will still work in a few > months.
In practice, convert-ly covers most of those. If you track the unstable versions, you'll have a larger maintenance cost. Crowdsourcing manual score updates on sites like Mutopia would also help keeping a _free_ corpus in shape, similar to the way that proprietary or private forks of free software are often not economically viable due to the resulting maintenance costs as compared to ongoing development. That does not mean that we should strive for planned obsolescence. But to the degree where we can't avoid it, we should turn it into an incentive for publishing free scores. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
