[ << Release work ]	[Top][Contents][Index][ ? ]			[ Build system notes >> ]
[ < Development phases ]		[  Up : Release work ]	[ Major release checklist > ]

11.2 Minor release checklist

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

Pre-release

1. Using any system with git pull access (not necessarily the GUB build machine), use the commands below to switch to the release branch, get changes and prepare the release announcement. 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
   

   • VERSION_DEVEL = the current development version (previous VERSION_DEVEL + 0.01)
   • VERSION_STABLE = the current stable version (probably no change here)
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 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:
   #   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
   

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:

   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 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

---

[ << Release work ]	[Top][Contents][Index][ ? ]			[ Build system notes >> ]
[ < Development phases ]		[  Up : Release work ]	[ Major release checklist > ]

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.18.2 (stable-branch).