11.2 Minor release checklist

A “minor release” means an update of y in 2.x.y.


  1. Don’t forget to prepare the GUB build machine by deleting and moving unneeded files: see “Subsequent builds” in Notes on builds with GUB.
  2. Using any system with git pull access (not necessarily the GUB build machine), use the commands below to do the following:
    • switch to the release branch
    • update the release branch from origin/master
    • update the translation files
    • create the release announcement
    • update the build versions.
      • VERSION_DEVEL = the current development version (previous VERSION_DEVEL + 0.01)
      • VERSION_STABLE = the current stable version (probably no change here)
    • update the “Welcome to LilyPond” version numbers to the version about to be released

    This requires a system which has the release/unstable branch. If you get a warning saying you are in detached HEAD state, then you should create a release/unstable branch with git checkout release/unstable.

    Check the environment variables are set as in Environment variables.

    You need to ensure you have a clean index and work tree. If the checkout displays modified files, you might want to run git reset --hard before continuing.

    git fetch
    git checkout release/unstable
    git merge origin/master
    make -C $LILYPOND_BUILD_DIR po-replace
    mv $LILYPOND_BUILD_DIR/po/lilypond.pot po/
    gedit Documentation/web/news-front.itexi Documentation/web/news.itexi
    gedit Documentation/web/news-headlines.itexi
    gedit VERSION
    gedit ly/Wel*.ly

    Editing the ‘news-headlines.itexi’ file is a bit tricky, since it contains URLs with escaped characters. An example of what is needed is that releasing 2.19.50 after the release of 2.19.49 needed the line:

      LilyPond 2.19.49 released - @emph{October 16, 2016}}

    to be changed to:

      LilyPond 2.19.50 released - @emph{November 6, 2016}}

    Don’t forget to update the entry above that line to show the latest release version.

  3. Commit, push, switch back to master (or wherever else):
    git commit -m "Release: bump VERSION_DEVEL." VERSION
    git commit -m "PO: update template." po/lilypond.pot
    git commit -m "Release: update news." Documentation/web/
    git commit -m "Release: bump Welcome versions." ly/Wel*.ly
    git push origin HEAD:release/unstable
    git checkout master
  4. If you do not have the previous release test-output tarball, download it and put it in regtests/
  5. Prepare GUB environment by running:
    ### my-gub.sh
    # special terminal, and default PATH environment.
    # import these special environment vars:
    env -i \
      HOME=$HOME \
      bash --rcfile my-bashrc
    ### my-bashrc
    export PS1="\[\e[1;33mGUB-ENV \w\]$ \[\e[0m\]"
    export PATH=$PATH
    export TERM=xterm
  6. Build release on GUB by running:
    make LILYPOND_BRANCH=release/unstable lilypond

    or something like:

    make LILYPOND_BRANCH=stable/2.16 lilypond
  7. Check the regtest comparison in ‘uploads/webtest/’ for any unintentional breakage. More info in Precompiled regression tests.
  8. If any work was done on GUB since the last release, upload binaries to a temporary location, ask for feedback, and wait a day or two in case there’s any major problems.

    Note: Always do this for a stable release.

Actual release

  1. If you’re not the right user on the webserver, remove the t from the rsync command in:
  2. Upload GUB by running:
    make lilypond-upload \
      LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \

    or something like:

    make lilypond-upload \
      LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \

Post release

  1. Update the current staging branch with the current news:
    git fetch
    git checkout origin/staging
    git merge origin/release/unstable
  2. Update ‘VERSION’ in lilypond git and upload changes:
    gedit VERSION
    • VERSION = what you just did +0.0.1
    git commit -m "Release: bump VERSION." VERSION
    git push origin HEAD:staging

    If the push fails with a message like

     ! [rejected]        HEAD -> staging (non-fast-forward)

    it means that somebody else updated the staging branch while you were preparing your change. In that case, you need to restart the Post Release process. Otherwise, proceed:

  3. Wait a few hours for the website to update.
  4. Email release notice to info-lilypond

LilyPond — Contributor’s Guide v2.19.52 (development-branch).