@enumerate
+@item
+Don't forget to prepare the GUB build machine by deleting and moving unneeded
+files: see @qq{Subsequent builds} in @ref{Notes on builds with GUB}.
+
@item
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
+build machine), use the commands below to do the following:
+
+@itemize
+@item
+switch to the release branch
+
+@item
+update the release branch from origin/master
+
+@item
+update the translation files
+
+@item
+create the release announcement
+
+@item
+update the build versions.
+
+@itemize
+@item
+VERSION_DEVEL = the current development version (previous VERSION_DEVEL + 0.01)
+
+@item
+VERSION_STABLE = the current stable version (probably no change here)
+
+@end itemize
+
+@item
+update the @qq{Welcome to LilyPond} version numbers to the version about to be
+released
+
+@end itemize
+
+This requires a system which has the release/unstable
branch. If you get a warning saying you are in @code{detached HEAD}
state, then you should create a release/unstable branch with
@code{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-new.itexi Documentation/web/news-old.itexi
+gedit Documentation/web/news-headlines.itexi
gedit VERSION
+gedit ly/Wel*.ly
@end example
-@itemize
-@item
-VERSION_DEVEL = the current development version (previous VERSION_DEVEL + 0.01)
+Editing the @file{news-headlines.itexi} file is a bit tricky, since it contains
+URLs with escaped characters. An example of what is needed is that releasing
+@code{2.19.50} after the release of @code{2.19.49} needed the line:
-@item
-VERSION_STABLE = the current stable version (probably no change here)
+@example
+@@uref@{news.html#LilyPond-2_002e19_002e49-released-October-16_002c-2016,
+ LilyPond 2.19.49 released - @@emph@{October 16, 2016@}@}
+@end example
-@end itemize
+to be changed to:
-@item
-Manually edit the two files @file{../ly/Welcome_to_LilyPond.ly} and
-@file{../ly/Welcome-to-LilyPond-MacOS.ly} such that the hard coded
-@code{\version} number reflects the version number about to be released.
+@example
+@@uref@{news.html#LilyPond-2_002e19_002e50-released-November-6_002c-2016,
+ LilyPond 2.19.50 released - @@emph@{November 6, 2016@}@}
+@end example
+
+Don't forget to update the entry above that line to show the latest release
+version.
@item
Commit, push, switch back to master (or wherever else):
@example
git commit -m "Release: bump VERSION_DEVEL." VERSION
-git commit -m "Release: bump VERSION_DEVEL." ly/Welcome_to_LilyPond.ly
-git commit -m "Release: bump VERSION_DEVEL." ly/Welcome-to-LilyPond-MacOS.ly
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
@end example
Download GUB and start the set up:
@example
-git clone git://github.com/gperciva/gub/gub.git
+git clone git://github.com/gperciva/gub.git
cd gub
make bootstrap
@end example
replace @code{2.15.33-1} with the latest build):
@smallexample
-@uref{http://lilypond.org/download/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2}
+@uref{http://lilypond.org/downloads/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2}
@end smallexample
-Copy the tarball into @file{gub/regtests/}, and tell the build
-system that you have done this:
+Copy the tarball into @file{regtests/}, and tell the build system that
+you have done this:
@example
touch regtests/ignore
website with the standard @code{make website} command. They run
hourly, 30 minutes apart. So - to update the front page of the
website, it's necessary to update @code{VERSION} and
-@code{news-front.itexi} in master and then wait for the cron
+@code{news-headlines.itexi} in master and then wait for the cron
jobs to run. (N.B. - this is done by pushing the changes to
staging and letting patchy do its checks before it pushes to
master).