lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backwards compatibility: \compressMusic, \scaleDurations, WHY WHY WH


From: Patrick McCarty
Subject: Re: Backwards compatibility: \compressMusic, \scaleDurations, WHY WHY WHY
Date: Tue, 5 Aug 2008 17:03:58 -0700

On Tue, Aug 5, 2008 at 4:05 PM, Steve Dunlop <address@hidden> wrote:
>
> You don't get it.  If you have an archive like Mutopia, where there are
> thousands of files and dozens of contributors, and mixed dependencies on
> versions, running conver-ly doesn't work.
>
> It doesn't work because two people working on the same file may not have
> the same version of Lilypond.  You can't get dozens of volunteer
> contributors to upgrade to the latest version all at once every time a
> new version comes out by snapping your fingers.
>
> It doesn't work because the same file may be included in two separate
> projects which use different versions of Lilypond because they rely on
> features and syntax much more difficult to fix than the example I cite.
> In some cases one of the projects may be in a "freeze" where only minor
> changes from proofreading are being admitted, and something major like a
> Lilypond upgrade would be problematic because the whole project would
> have to be re-proofread to be sure things like spacing weren't adversely
> affected.
>
> It doesn't work because the person who needs the change may not be the
> maintainer of the file, and the maintainer of the file may have other
> things to do besides run convert-ly on some old project.
>
> Unless all you ever want Lilypond to be is a program used by individuals
> typesetting a handful of their favorite works, rather than, say, the
> lingua Franca of the open content classical music movement.

I mentioned convert-ly because this *is* LilyPond's method of
providing (partial) backwards compatibility.

There is a trade-off involved:

1) Provide complete backwards compatibility, but sacrifice program
efficiency/speed and retain tons of deprecated code
2) Provide partial backwards compatibility, and retain program efficiency/speed

Since changes to syntax/structure are typically improvements and are
*forward* looking, there isn't as much interest in the way LilyPond
*used to be*.

You do raise a lot of interesting points though.  I'm not the best
person to address these concerns though.

-Patrick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]