Werner LEMBERG <w...@gnu.org> writes: >>> Forget that: it seems that the tag already exists, it's just not >>> present on the master branch (because it's in the stable branch): >>> 050744bbb706525840a3014cd72b06fde945fa4d > > OK. > >> Yes, I have it here as well. > > Hmm. So why do we have > > commit 9918cd9f8d8f5461c6ad7e086fd93de59960eb95 > Author: Phil Holmes <m...@philholmes.net> > Date: Sun Nov 24 22:05:16 2013 +0000 > > Release: bump VERSION. > > in the `master' branch? This looks incorrect to me, given that we > currently derive 2.17.9X tarballs from the `stable' branch, right?
No. VERSION_STABLE and VERSION_DEVEL in the master branch define the versions that our web pages declare the latest available version. The version of the respective binary, in contrast, is MAJOR_VERSION, MINOR_VERSION, PATCH_LEVEL. So even when we have parallel development, VERSION_STABLE and VERSION_DEVEL point to the last _released_ versions that can be found in the web pages. What a binary will be, is in MAJOR_VERSION, MINOR_VERSION, PATCH_LEVEL. The next scheduled versions will be 2.19.0 from master, and 2.17.97 from the stable branch. In order not to confuse people more than necessary, we will not release 2.19.0 before 2.18.0. The release scheme would make that perfectly feasible, but that's not something we want to do. I'm not totally sure that next weekend will not be 2.18.0 instead of 2.17.97, but there are still a few open questions that could prove critical. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
