Re: Evolutionary User Strategy - A Compromise

[Colin Wilding]

Maybe a distinction should be made between bug fixes and other changes, e.g
new features and syntax changes.  I would not expect the developers to
preserve bugs, but beyond that I think it is reasonable to hope that a file
I create in version 3.0 should look the same if I process it using version
3.1.  Or at least that the instructions I used should still work and should
have the same meaning.

When I use a specific tweak, such as adding an offset to a piece of markup,
I don't expect it to be particularly stable - if the system breaks change,
for example, then I have to review such tweaks to check that they still have
the right effect.  So I can live with having to do that for new versions.

All I'm trying to do here is suggest an approach that makes it easier for
users to continue to use Lilypond when new versions come out.  The current
lack of stability is a major barrier to using Lilypond for some people.

Colin





Erik Sandberg-2 wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 
-- 
View this message in context: 
http://www.nabble.com/Evolutionary-User-Strategery-tf1906879.html#a5304610
Sent from the Gnu - Lilypond - User forum at Nabble.com.