Joseph Rushton Wakeling <joseph.wakel...@webdrake.net> writes: > On 24/07/12 10:09, Graham Percival wrote: >> Let’s decide whether to try to stabilize the syntax or not. What >> type of project do we want LilyPond to be? What kinds of >> guarantees (or at least firm intentions) do we want to give to >> users with respect to lilypond 2 or 5 years from now being able to >> read their current ly files? > > As a first step, surely it's important to understand what are the > typical sources of conversion problems, i.e. what kind of syntax > changes can convert-ly not deal with? > > It seems to me that \override statements and custom-written Scheme > inherently come with a "may break in future" health warning > (especially the latter). I don't think improvements to the language > should be held back for the sake of such explicit departures from > default behaviour. > >> Given that, LilyPond is not suitable as an archival format for >> music. > > That surely depends on whether your archive can also maintain earlier > versions of LilyPond to compile its older files with.
And earlier versions of GCC to compile its older LilyPond versions with. > How feasible is it for LilyPond to support a deprecation mechanism for > syntax? E.g. so that when compiling you might get an error message, > > [such-and-such a syntax element] is deprecated syntax that will be > removed from a future version of LilyPond. Use [new syntax] > instead. At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies of music like Mutopia satisfactorily. > Or alternatively, to simply maintain in LP the previous syntax as a > separate option, so that for example > > lilypond file.ly -- uses the current standard syntax > lilypond --deprecated file.ly -- uses the previous syntax If it was simply... > My overall feeling on this is that while there are areas of "standard" > modern musical notation > [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] that > aren't supported by LilyPond, it's difficult to guarantee syntax > stability. So perhaps a first step is to define the subset of > _musical_ notation that you want to provide stable support for. Sounds to me like that was what Graham proposed in the first place. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
