lilypond-user
[Top][All Lists]
Advanced

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

Re: Evolutionary User Strategy - A Compromise


From: Erik Sandberg
Subject: Re: Evolutionary User Strategy - A Compromise
Date: Wed, 12 Jul 2006 13:21:28 +0200
User-agent: KMail/1.9.1

On Wednesday 12 July 2006 12:00, Colin Wilding wrote:
> This is an important dilemma for many users, I think - we want to have all
> the fixes and features in each new version, but find it frustrating when
> music produced in earlier versions needs time-consuming manual editing to
> upgrade.
>
> Can I suggest a compromise?
>
> I accept that Lilypond has been evolving rapidly and feel privileged to
> have been able to use it (and contribute comments) during that evolution.
>
> At some point, though, the evolution should slow down:  the developers
> should feel happy with the basic structure and syntax and the users should
> be able to expect that music written for today?s version will look the same
> in tomorrow?s.

What do you mean by 'the same'? Is it OK if the output suddenly looks better 
because a bug has been fixed?
If yes, then you still have the problem that an upgrade may break your tweaks 
that work around layout bugs.
If no, then development will be very difficult because all bugs have to be 
preserved.

If there's sufficient community interest in maintaining and developing a 
conservative version of lilypond, then anyone can make a fork; however, I 
doubt any of the current developers would join. Lily is currently at a pretty 
early stage of development IMHO.

> How about making a resolution that from version 3.0 onwards Lilypond will
> be backwards-compatible:  in other words, the current version will
> correctly display a file written in any earlier version 3.x without the
> need for conversion.

I think 2.4 files are fairly forward compatible; there have been no major 
changes that I know of. 

There's also the question of what you mean by compatibility: Very advanced 
tweaks usually rely on the way lily's internals are organised, which may 
change over time. Since lily contains a Turing-complete programming language, 
for some language updates it is thereby _impossible_ to create a script that 
upgrades _all_ .ly files perfectly. There are also deprecated features that 
are dropped sometimes, this causes a kind of backward incompatibility.

-- 
Erik





reply via email to

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