11.2 Minor release checklist

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


  1. 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 VERSION
    gedit ly/Wel*.ly
  2. 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
  3. If you do not have the previous release test-output tarball, download it and put it in regtests/
  4. 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
  5. Build release on GUB by running:
    make LILYPOND_BRANCH=release/unstable lilypond

    or something like:

    make LILYPOND_BRANCH=stable/2.16 lilypond
  6. Check the regtest comparison in ‘uploads/webtest/’ for any unintentional breakage. More info in Precompiled regression tests.
  7. 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.12 (development-branch).