Re: Frescobaldi’s use of the version statement

[David Wright]

On Fri 09 Mar 2018 at 23:02:53 (+0100), Simon Albrecht wrote:
> On 09.03.2018 17:13, David Wright wrote:
> >>You can even use Frescobaldi's option "Automatically choose LilyPond version
> >>from document".
> >Ouch. I hadn't come across that one. Sounds really bad to me.
> >a) you're not really in control of what's running,
> 
> Huh? You can choose which of the LilyPond versions (that you have
> installed) you make available to Frescobaldi. Then you start on a
> project, and by typing the \version statement you also tell
> Frescobaldi which LilyPond version to compile it with (assuming that
> version is installed – fallback options are handled gracefully). In
> the ‘terrible’ case that the version specified by the version
> statement or the one chosen by Frescobaldi isn’t the one you wanted
> to compile it with, you’d be able to see in the log panel.
> I don’t see any problem with that.

When the problem under discussion appears to be one of versioning,
it doesn't seem a wise course of action to add one more method of
having version changes made under ones feet.

> >b) what happening when all the includes have different version numbers,
> 
> Frescobaldi will always go after the first one.

In the case cited, the problem started when the OP was running old
source files. If there were includes of, say, a user's collection
of .ily files, then one is inviting more wasted runs due to
"program too old" errors.

> >c) it sends a misleading message to a naive user that \version
> >    statements are meant to*do*  something, when that is not their function.
> >
> >Just for interest, here are the version statements from the files
> >installed by lilypond-2.19.80-1.linux-64.sh
> >
> >\version "2.14.0"
> >\version "2.16.0"
> >\version "2.17.25"
> >\version "2.17.6"
> >\version "2.18.2"
> >\version "2.19.16"
> >\version "2.19.22"
> >\version "2.19.25"
> >\version "2.19.29"
> >\version "2.19.46"
> >\version "2.19.80"
> 
> Development policy states that the \version statements will only be
> updated when the file is actually changed. So all this means is that
> some .ly file in the source code has been around without change
> since 2.14.0, some were updated quite recently, etc.

Yes, I was aware of that. The point I was making was that any
collection of *ly files is likely to contain a variety of version
statements, and the one selected from a particular source file might
not be appropriate for all the files that get compiled in that run.

Cheers,
David.