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 > lilypond-user@gnu.org > 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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
