Re: Coexisting 2.8 with 2.4

[Nicolas Sceaux]

Graham Percival <address@hidden> writes:

> Fairchild wrote:
>> Many have invested extensive effort in creating quality scores with various
>> versions.
>
> The "guidelines for writing lilypond files" section of the manual
> attempts to mitigate this.  By writing lilypond files carefully, you can
> reduce the problems associated with upgrading versions.
>
>>  To encourage upgrading there should be some automated mechanism
>> for upward compatibility, or earlier versions should be supported.
>> The string replacement capabilities in convert-ly are useful, but
>> far from
>> adequate.
>
> Additional support for older versions requires more effort.  There are
> three reasons that people work on lilypond:
> 1)  Getting paid for a specific features.  (see the "sponsoring" links)
> 2)  Solving a personal problem (ie if I were a programmer and were
> annoyed by a bug, I could fix the bug and send my patch in).
> 3)  Contributing due to a vague sense of owing something to the
> community.  (such as basically all my doc work)
> [...]

Hadn't I read Graham's post, I'd have made a way less polite answer. 

And I second Graham's remark on the actual upgrade effort when LilyPond
input file are well structured. A few pieces of advice:

1) put your notes in separate files for each voice, without any
   structure around.

--- violin.ly ---
g'4 c''8. e''16 g''8 a'' g''4
...
-----------------

The same way, lyrics, figured bass, etc are in separate files. When I
upgraded Giulio Cesare score from 1.6 to 2.6, I didn't even run
convert-ly on lyrics and figured bass files, for the syntax had not
changed for them. No headaches. And since then, I've upgraded this score
to current CVS without even touching the note files.

2) As soon as you have to use an \override in note files, abstract it
   with dedicated variables or functions, which will be defined in a
   common file.

That way, the upgrade effort for note files is zero. Only the common
definition file has to be upgraded if property names change for
instance.

3) Define music functions and markup commands when you see a repeating
   pattern. Changing the body of music functions is costless. For
   instance, if you have several instances of the following pattern:

   \new Voice = "foo" <<
      \set Voice . autoBeaming = ##f
      \set Staff . instrument = \markup "Character Name"
      ..music..
   >> \lyricsto "foo" \new Lyrics { ..lyrics.. }

then write a music function that will generate that expression. If the
autoBeaming property name changes in the future, there is only 1 point
in you project files that you have to change. The structure files (were
\score blocks are defined) are the most fragile. Abuse of music
functions inside them.

nicolas