Re: Evolutionary User Strategy - A Compromise

[Colin Wilding]

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.

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.

For the developers that would mean retaining the behaviour of the earlier
versions, but only back as far as 3.0.  For the users it would mean that
once they had updated their files to 3.0 they could continue to use them
without further modification if they wished.

If the backward compatibilty subsequently became a burden then the
developers could start again with version 4.0 and write a convert-ly just
from 3.x to 4.0.


Colin

Fairchild wrote:
> 
> LilyPonders -
> 
> Users dealing with LilyPond as it evolves are presented with difficult
> choices, none good.
> 
> If one knows a score will be completed quickly, never be revisited, and
> components of the code structure never will be reused, the choice is easy:
> save and share graphics only, dump the ly files for completed scores, and
> move on to the latest stable version.  I'm not that prescient.
> 
> Constantly adopting the latest version allows use of the latest features,
> feedback helps the developers, and the developers provide support. 
> However,
> modifying 'finished' scores to be acceptable by the latest version is not
> reasonable.  Upgrade modifications require significant effort.  The
> convert-ly program helps, but misses a lot.  
> 
> It is tempting to select a stable version and stick with it.  Scores can
> be
> revisited easily.  Syntax and semantics are stable.  Downside: the feature
> set never gets better and support will fade away unless a sufficient
> number
> of users make the same choice and help each other.
> 
> It is possible to maintain multiple LilyPond versions.  This allows
> revisiting old scores, but at a price.  The operational environment
> becomes
> more and more confusing as versions accumulate.
> 
> I have coded tens of scores, most with version 2.4.6, and spent several
> hours attempting to move just one (a smaller one) of them to 2.8.5.  After
> using convert-ly and correcting for its errors, much remains to be done,
> especially to position the right text font.  Conclusion: repetitive
> conversion of scores is untenable.
> 
> The only reasonable solution is to maintain upward compatibility in the
> LilyPond processor.  New features should be added without changing
> existing
> syntax.  If it is deemed absolutely necessary to change semantics or
> define
> conflicting syntax, provide for optional interpretations based on the
> version specified.  Older ly files should generate consistent results as
> LilyPond migrates.  More exhaustive regression tests are necessary.
> 
> If you can identify a better way, or have other comments, please respond.
> 
>                                    - Bruce
> 
> 
> 
> _______________________________________________
> 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#a5285941
Sent from the Gnu - Lilypond - User forum at Nabble.com.