On 7/10/06, Fairchild <[EMAIL PROTECTED]> wrote:
Erik -
Thanks for contributing to this thread. It is attempting to deal with an
important unresolved issue: seamless evolutionary transitioning of ly files.
Your suggested solution requires "n" versions residing entirely in the
user's machine, which would, as you point out, increase resident code by a
factor of "n". The code switching option requires parallel code only for
features that are interpreted differently for different versions, only
marginally increasing the size of the newer versions - far less size, and
hassle, than retaining several versions.
Different lily versions use different data structures and interfaces internally.
If we would have n different versions of e.g. each engraver, and the
interface between iterators and engravers would change a tiny bit
(which it does now and then), then we would need to update n different
versions of each engraver, which is n times as much work as now; it
would also mean n times more testing, and n times more bugs. Keep in
mind also that the .ly grammar changes between versions, so you will
need to have a separate parser for each version.
That said, you are of course welcome to write a patch that makes lily
2.9 support 2.4 files. My guess is that Han-Wen won't accept the
patch, but if you really want the feature you can always fork the
lilypond project, and start a lilypond-legacy project.
BTW, if you're concerned about the extra size consumption that it
requires to have n different versions, you could consider compressing
your file system. If there is much code in common between lily
versions, then a smart compression algorithm might detect this and
reduce the extra space consumed.
Erik
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
