[ << Release work ][Top][Contents][ Modifying the Emmentaler font >> ]
[ < Development phases ][ Up : Release work ][]

11.2 Minor release checklist

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

Pre-release

  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 switch 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 switch release/unstable
git merge origin/master
make -C $LILYPOND_BUILD_DIR po-replace
mv $LILYPOND_BUILD_DIR/po/lilypond.pot po/
gedit Documentation/en/web/news-new.itexi Documentation/en/web/news-old.itexi
gedit Documentation/en/web/news-headlines.itexi
gedit VERSION
gedit ly/Wel*.ly
  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/en/web/
git commit -m "Release: bump Welcome versions." ly/Wel*.ly
git push origin HEAD:release/unstable
git switch 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:
#   HOME, HTTP_PROXY, TERM
env -i \
  HOME=$HOME \
  HTTP_PROXY=$HTTP_PROXY \
  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: 
    test-lily/rsync-lily-doc.py
test-lily/rsync-test.py
  2. Upload GUB by running: 
    make lilypond-upload \
  LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
  LILYPOND_BRANCH=release/unstable

    or something like: 

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

Post release

  1. Update the current master branch with the current news: 
    git fetch
git switch origin/master
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:release/unstable
  3. Create a merge request from release/unstable to merge the changes into master.
  4. Update the website as described in Uploading website.
  5. Email release notice to info-lilypond
  6. Create a new release at GitLab by selecting the existing tag and milestone.
  7. Update the milestones at GitLab:
    1. Make sure all merge requests and issues are added to the milestone of the released version. Fill in the due date and close it.
    2. Create a new milestone for the next release (unless no more bugfix release is planned) and set the start date.
[ << Release work ][Top][Contents][ Modifying the Emmentaler font >> ]
[ < Development phases ][ Up : Release work ][]

<< Back to Documentation Index

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