@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}.
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
@end example
@item
Commit, push, switch back to master (or wherever else):
@example
+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
@end example
or something like:
@example
-make LILYPOND_BRANCH=stable/2.12 lilypond
+make LILYPOND_BRANCH=stable/2.16 lilypond
@end example
-@item Check the regtest comparison in @file{uploads/webtest/} for
+@item
+Check the regtest comparison in @file{uploads/webtest/} for
any unintentional breakage. More info in
@ref{Precompiled regression tests}.
-@item If any work was done on GUB since the last release, upload
+@item
+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.
test-lily/rsync-test.py
@end example
-@code{graham} owns v2.13; @code{han-wen} owns v2.12.
-
@item Upload GUB by running:
@example
@enumerate
-@item Update the current staging branch with the current news:
+@item
+Update the current staging branch with the current news:
@example
git fetch
git merge origin/release/unstable
@end example
-@item Update @file{VERSION} in lilypond git and upload changes:
+@item
+Update @file{VERSION} in lilypond git and upload changes:
@example
-vi VERSION
+gedit VERSION
@end example
@itemize
@item
VERSION = what you just did +0.0.1
-
-@item
-DEVEL_VERSION = what you just did (i.e. is now online)
-
-@item
-STABLE_VERSION = what's online (probably no change here)
-
@end itemize
@example
-git commit -m "Release: bump version." VERSION
+git commit -m "Release: bump VERSION." VERSION
git push origin HEAD:staging
@end example
preparing your change. In that case, you need to restart the Post
Release process. Otherwise, proceed:
-@item (for now) do a @code{make doc} and manually upload:
-
-@example
-### 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
-@end example
-
@item Wait a few hours for the website to update.
@item Email release notice to @code{info-lilypond}
@subheading Main requirements
-This is the current official guidelines.
+These are the current official guidelines.
@itemize
@item
@end example
@item
-Check for altered regtests, and document as necessary. (update
-numbers in the following command as appropriate)
+Check for altered regtests, and document as necessary:
@example
-git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
+git diff -u -r release/2.@var{FIRST-CURRENT-STABLE} \
+ -r release/2.@var{LAST-CURRENT-DEVELOPMENT} input/regression/
@end example
@end itemize
Make directories on lilypond.org:
@example
-~/web/download/sources/v2.14
-~/web/download/sources/v2.15
+~/download/sources/v2.@var{NEW-STABLE}
+~/download/sources/v2.@var{NEW-DEVELOPMENT}
@end example
@item
Shortly after the release, move all current contributors to
-previous contributors in:
+previous contributors in
+@file{Documentation/included/authors.itexi}.
-@example
-Documentation/included/authors.itexi
-@end example
-
-Also, delete old material in:
+@item
+Delete old material in @file{Documentation/changes.tely}, but
+don't forget to check it still compiles! Also update the version
+numbers:
@example
-Documentation/changes.tely
+@@node Top
+@@top New features in 2.@var{NEW-STABLE} since 2.@var{OLD-STABLE}
@end example
-but don't forget to check it still compiles! also update the
-version numbers.
-
@item
Website:
@itemize
@item
make a link from the old unstable to the next stable in
-lilypond.org's /doc/ dir. Keep all previous unstable->stable doc
-symlinks.
+lilypond.org's @file{/doc/} dir. Keep all previous unstable->stable
+doc symlinks.
Also, make the old docs self-contained -- if there's a redirect in
-/doc/v2.12/Documentation/index.html , replace it with the
-index.html.old-2.12 files.
+@file{/doc/v2.@var{OLD-STABLE}/Documentation/index.html} , replace it with the
+@file{index.html.old-2.@var{OLD-STABLE}} files.
The post-2.13 docs will need another way of handling the
self-containment. It won't be hard to whip up a python script
-that changes the link to ../../../../manuals.html to
-../website/manuals.html , but it's still a 30-minute task that
+that changes the link to @file{../../../../manuals.html} to
+@file{../website/manuals.html}, but it's still a 30-minute task that
needs to be done before 2.16.
@item
-doc auto redirects to v2.LATEST-STABLE
+doc auto redirects to @code{v2.@var{NEW-STABLE}}
@item
-add these two lines to http://www.lilypond.org/robots.txt:
+add these two lines to @file{Documentation/web/server/robots.txt}:
@example
-Disallow: /doc/v2.PREVIOUS-STABLE/
-Disallow: /doc/v2.CURRENT-DEVELOPMENT/
+Disallow: /doc/v2.@var{OLD-STABLE}/
+Disallow: /doc/v2.@var{NEW-DEVELOPMENT}/
@end example
@end itemize
@itemize
@item
submit po template for translation: send url of tarball to
-coordinator@@translationproject.org, mentioning lilypond-VERSION.pot
+@email{coordinator@@translationproject.org}, mentioning
+lilypond-VERSION.pot
@item
update links to distros providing lilypond packages? link in:
@file{Documentation/web/download.itexi}
-This has nothing to do with the release, but it's a "periodic
-maintenance" task that might make sense to include with releases.
+This has nothing to do with the release, but it's a @qq{periodic
+maintenance} task that might make sense to include with releases.
@item
Send announcements to...
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
projects / lilypond.git / blobdiff