[ << 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. Switch to the release branch, get changes, prep release announcement. This requires 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 origin/release/unstable
   git merge origin
   vi Documentation/web/news-front.itexi Documentation/web/news.itexi
   

2. Commit, push, switch back to master (or wherever else):

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

   graham owns v2.13; han-wen owns v2.12.

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. Switch back to master and get the updated news:

   git checkout origin/staging
   git merge origin/release/unstable
   

2. Update ‘VERSION’ in lilypond git and upload changes:

   vi VERSION
   

   • VERSION = what you just did +0.0.1
   • DEVEL_VERSION = what you just did (i.e. is now online)
   • STABLE_VERSION = what’s online (probably no change here)

   git commit -m "Release: bump version." VERSION
   git push origin HEAD:staging
   

3. (for now) do a make doc and manually upload:

   ### upload-lily-web-media.sh
   #!/bin/sh
   BUILD_DIR=$HOME/src/build-lilypond
   
   PICS=$BUILD_DIR/Documentation/pictures/out-www/
   EXAMPLES=$BUILD_DIR/Documentation/ly-examples/out-www/
   
   cd $BUILD_DIR
   rsync -a $PICS graham@lilypond.org:media/pictures
   rsync -a $EXAMPLES graham@lilypond.org:media/ly-examples
   

4. Wait a few hours for the website to update.
5. 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