Recently I upgraded to lilypond 2.19.80, and now lilypond tells me:

warning: no \version statement found, please add \version "2.19.80"

Now, I have that version number in a special include file that I use for all my scores. Earlier versions of lilypond did not have a problem with this.

My music still compiles just fine; but is there a way to get rid of that error message? I want to keep the version number in the include file. The inclusion is on the very first line of the score file.

  • I can not reproduce your problem. I have main.ly with only \include "included.ly" in it, which contains only \version "2.19.80" {c'} so that main.ly compiles by including the other. The result is a c' withour any error.
    – Paco Vila
    Mar 7, 2018 at 12:37
  • Strange, when I try the same thing, it does give me the warning. It does this even if there nothing in the include except the version number, and nothing in the music except the title.
    – bgmCoder
    Mar 7, 2018 at 16:22
  • If there is nothing except the title, no PDF is created, so be careful and double-check you are getting the expected output. As for the actual need of the version statement in every file, It is very strange because in my system it is not needed. A single instance in any of the included files or the main file is enough. v2.19.81 is out, so maybe we should both install it and talk again later.
    – Paco Vila
    Mar 8, 2018 at 11:43
  • It happens with every file I compile - even ones with no errors, and even the simplest of scripts. I could try again with .81.
    – bgmCoder
    Mar 9, 2018 at 17:47

3 Answers 3


See here for the original issue: https://sourceforge.net/p/testlilyissues/issues/5180/


#5180 Inconsistent "no \version statement" warning

I don’t know who might care about this, but when Lilypond processes an empty file, it prints a warning about not finding a \version statement, yet when it processes a file containing only \include “english.ly”, it does not mention that there is no \version statement.


Looks like we should outcomment the \version statements in files intended for inclusion by the user. That way they will not mess with the version of the session while still being accessible to convert-ly.

Or we make \include restore the version-seen status at its end (or let it only be set in main input).

See here for the change: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=8f95c1d407d42ce3f3db46c2d4e7a4479d186429

Commit message:

Issue 5180: Require \version statement in main file

The warning about a missing \version statement got omitted when including a file (such as a language definition file) containing one, even though it does not really relate to the version of the main file.

Thus, according to the developers, it was not that earlier versions did not have a problem, and now it does — rather, earlier versions had a problem, and they fixed it. To answer your question of “why the version number isn't respected in the include,” the answer can be gleaned in the code there (although I am only guessing at what it means). As for why they chose this, it sounds like the “version” statement was counting only for the \included file and not for the one that was doing the compiling. (I used to use it this way.) That is my guess. I could be wrong.

  • Wow, that's a bit of sleuthing! Maybe they didn't expect someone to use the way I did. Thanks for doing this.
    – bgmCoder
    Mar 10, 2018 at 0:56

I think the "logic" behind the request to add the \version to the lilypond file is that whatever file you are writing, it "works" on a given version: the one you are using. It might work, probably on later versions... but if you are using some feature that just came out with the specific version you are using and you try to use the file on a previous version of lilypond, it will break. There might also be some tweaks in the way the same lilypond file will be rendered on different versions of lilypond... so it's just to make sure that what you got as the file is actually what other people will get. My tip: just add the version to the file.

  • Thinking about it, I think you might be right. My reasoning in the first place was that all the pieces for this project would have the same setup, and by production time I would have modified them all to work at that version. But putting it in the file might be better anyway. However, I was asking why the version number isn't respected in the include.
    – bgmCoder
    Mar 7, 2018 at 16:14
  • Hmm... interesting. Perhaps they want to force people to do it on a "per file" basis?
    – eftshift0
    Mar 7, 2018 at 16:26
  • The logic is actually a little different. The version statement is just an indication to the update-ly converter so that it knows which version to convert from. You can manually tell this to the converter, but I think it is better to get the actual version read from the file itself.
    – Paco Vila
    Mar 8, 2018 at 11:55

This is working as intended. The background is that LilyPond syntax changes across versions and you keep it in line using the convert-ly utility which interprets the \version line and updates it together with updating syntax. Now it would be feasible to include an outcommented \version line, but then LilyPond itself would no longer check it, defeating part of its purpose. Also it turns out that external libraries tend to contain it.

So no, there is no way to specify the version of your main file's syntax with a \version line in an included file, and doing that would make it very complex to reasonably update some project using convert-ly. So better just make it a habit to put a \version statement in every file as intended.

  • Well, in the last version I was using (2.19?) I did it all the time, which, when I upgraded, is why I posted this question. I think Neal pretty much summarized the reason. But for other users, I think that mentioning the convert-ly could be helpful.
    – bgmCoder
    Mar 12, 2018 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.