Re: [GLISS] differentiating pre/post/neutral commands

[David Kastrup]

Reinhold Kainhofer <address@hidden> 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