On Thu, Jul 05, 2018 at 08:49:12PM +0200, David Kastrup wrote: > Graham Percival <gra...@percival-music.ca> writes: > > I suspect that the issue is that we only want a string in the form > > "2.19", and it was easier to create such a string by concatenating > > MAJOR_VERSION and MINOR_VERSION, instead of taking VERSION_STABLE > > of "2.19.65" and removing the final ".xy" > > Hm. I've done a change using VERSION_DEVEL locally but I am not sure > whether there is one valid strategy for both development and stable > releases. > > I am not sure I understand the problem.
Sorry, I'm not certain if this is still an issue. Here's the problem as I recall it. 1) The regular MAJOR_VERSION / MINOR_VERSION / PATCH_LEVEL points to the *next* lilypond release in git master. This is so that if a developer compiles the binary, there's a distinction between ./lilypond --version and lilypond --version (assuming that she has an officially released lilypond in her $PATH). 2) Pages like http://lilypond.org/unix.html http://lilypond.org/development.html are generated from Documentation/web/download.itexi Documentation/web/community.itexi from git master. These need to point to the latest *released* versions, not the "n+1" version that one gets from compiling. To see exactly how VERSION_STABLE and VERSION_DEVEL are used, $ git grep versionStable -- Documentation/web $ git grep versionDevel -- Documentation/web Cheers, - Graham _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
