Re: Evolutionary User Strategery

[Simon Dahlbacka]

Bruce, sorry to be rude but:

Being forced to absolute backward compatibility sucks, and having to
keep compatibility with e.g. 2.4 2.6 and 2.8 sucks even more, and
makes the code base bloated, less maintainable and probably a lot of
#ifdefs of what not that leads to more bugs..

Put it another way, you don't want to write your .ly files in such a
way that you can use whatever lilypond version to "compile" them and
get a perfect result. The developers most certainly does not want
absolute backwards compatibility, and they even bother so much as to
provide convert-ly to make the transition forward easier. Whose
arguments do you thing weigh more? Most developers develop lilypond in
their spare time just for the fun of it for all I know..

After all, this is free software, if you like, you can make your own
"compatible-with-everything-even-all-the-bugs" fork project..

/S

On 7/10/06, Fairchild <address@hidden> 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.
>
> Marginally increasing the single package size is not a concern.  Through the
> generations, memory and speed have increased to accommodate applications -
> or maybe the other way around.  The first computer I used had 2000
> bi-quinary ten-digit words on a drum.  Long-term memory was punched cards.
> It was a fantastic improvement over its predecessor, the Card Programmed
> Calculator.
>
> Increasing processing time is a consideration, but testing a flag to select
> from version-specific code segments would be barely measurable.
>
>                                  - Bruce
>
> -----Original Message-----
> From: Erik Sandberg [mailto:address@hidden
> Sent: Monday, July 10, 2006 3:12 AM
> To: Fairchild
> Cc: address@hidden
> Subject: Re: Evolutionary User Strategery
>
>
> On 7/9/06, Fairchild <address@hidden> wrote:
> > New scores could use new features and not have to work around the bugs
> > of earlier versions.  Older scores that have been carefully tuned,
> > compensating for earlier bugs, would continue to produce the intended
> > result without having to be overhauled.  There would be no need to
> > maintain multiple versions.
>
> This basically implies that all old versions of lily must be included in the
> new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6
> and 2.4. Which means that the lilypond package grows by a factor 4. I think
> a better solution would be that you create a script locally, which parses
> the input ly file, reads the \version statement, and picks which lilypond
> version to use to compile your ly file.
>
> Erik
>
>
>
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-user