@chapter Release work
@menu
-* Development phases::
-* Minor release checklist::
-* Major release checklist::
-* Release extra notes::
+* Development phases::
+* Minor release checklist::
+* Major release checklist::
+* Release extra notes::
+* Administrative policies::
@end menu
@item @strong{Release prep phase}:
-FIXME: I don't like that name.
+TODO: I don't like that name.
A new git branch @code{stable/2.x} is created, and a major release
is made in two weeks.
@enumerate
-@item Add a news item to @file{Documentation/web/news-front.itexi}
+@item
+Switch to the release branch, get changes, prep release
+announcement:
-@item Check that lilypond builds from scratch in an out-of-tree
-build.
+@example
+git checkout release/unstable
+git merge origin
+vi Documentation/web/news-front.itexi Documentation/web/news.itexi
+@end example
+
+@item
+Commit, push, switch back to master:
+
+@example
+git commit -m "Release: update news." Documentation/web/
+git push origin
+git checkout master
+git merge release/unstable
+@end example
+
+@item (optional) Check that lilypond builds from scratch in an
+out-of-tree build.
@item
If you do not have the previous release test-output tarball, download
@item Build release on GUB by running:
@example
-make lilypond
+make LILYPOND_BRANCH=release/unstable lilypond
@end example
@noindent
make LILYPOND_BRANCH=stable/2.12 lilypond
@end example
-
@item Check the regtest comparison in @file{uploads/webtest/} for
any unintentional breakage.
-@item Check if the mingw build contains lilypad.exe; when you find
-that it doesn't, rebuild @code{mingw::lilypond-installer}. Repeat
-as necessary.
-
-@uref{http://code.google.com/p/lilypond/issues/detail?id=901}
+Note that this test uses the bounding boxes inside lilypond.
+Errors in ghostscript don't generate differences inside lilypond,
+so they are not registered in the regtest comparison.
@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
@end enumerate
-@subheading Post-release
+@subheading Actual release
@enumerate
make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
@end example
+@end enumerate
+
+
+@subheading Post release
+
+@enumerate
+
+@item Switch back to master and get the updated news:
+
+@example
+git checkout master
+git merge release/unstable
+@end example
-@item Update @file{VERSION} in lilypond git.
+@item Update @file{VERSION} in lilypond git:
+
+@example
+VERSION = what you just did +0.0.1
+DEVEL_VERSION = what you just did (i.e. is now online)
+STABLE_VERSION = what's online
+@end example
+
+@item Push changes.
+
+@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/web/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.
@end enumerate
+
@node Major release checklist
@section Major release checklist
A @qq{major release} means an update of @code{x} in @code{2.x.0}.
+- happens when we have 0 Critical issues for two weeks (14 days).
+
+
Before release:
* write release notes. note: stringent size requirements for
Disallow: /doc/v2.CURRENT-DEVELOPMENT/
@end example
+- check for emergencies the docs:
+
+@example
+grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
+ --exclude "snippets/*" ????*/*
+@end example
+
+- check for altered regtests, and document as necessary. (update
+ tags as appropriate)
+
+@example
+git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
+@end example
+
+
News:
comp.music.research
@node Release extra notes
@section Release extra notes
-If releasing stable/2.12, then:
+@subsubheading Regenerating regression tests
-- apply doc patch: patches/rsync-lily.patch (or something like
- that)
+Regenerating regtests (if the lilypond-book naming has changed):
-- change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
- to "lilypond-web.info"
+@itemize
+@item
+git checkout release/lilypond-X.Y.Z-A
-GENERAL STUFF TO BE MOVED ELSEWHERE
+@item
+take lilypond-book and any related makefile updates from the
+latest git.
-Regenerating regtests (if the lilypond-book naming has changed):
+@item
+- configure; make; make test
-- git checkout release/lilypond-X.Y.Z-A
+@item
+tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
-- take lilypond-book and any related makefile updates from the
- latest git.
+@item
+mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
-- configure; make; make test
+@item
+cd ../gub/regtests/
-- tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2
- input/regression/out-test/
+@item
+make lilypond
-- mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
+@end itemize
-- cd ../gub/regtests/
-- make lilypond
+@subsubheading stable/2.12
+If releasing stable/2.12, then:
-New contributor / mentor idea:
+@itemize
-- tell them to spend 10 minutes on a problem, then give up and ask
- for help from their mentor
+@item
+apply doc patch: patches/rsync-lily.patch (or something like
+that)
-- the mentor should tell them if a "make clean; make" (or the same
- for docs) is required
+@item
+change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
+to "lilypond-web.info"
+@end itemize
+
+@subsubheading Updating a release (changing a in x.y.z-a)
+
+Really tentative instructions, almost certainly can be done
+better.
+
+@enumerate
+
+@item
+change the VERSION back to release you want. push change.
+(hopefully you'll have forgotten to update it when you made your
+last release)
+
+@item
+make sure that there aren't any lilypond files floating around in
+target/ (like usr/bin/lilypond).
+
+@item
+build the specific package(s) you want, i.e.
+
+@example
+bin/gub mingw::lilypond-installer
+make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
+bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
+@end example
+
+or
+build everything with the normal "make lilypond", then (maybe)
+manually delete stuff you don't want to upload.
-Latest website:
+@item
+manually upload them. good luck figuring out the rsync
+command(s). Hints are in test-lily/
+
+or
-- generated hourly on lilypond.org. Only split-HTML; big-html and
- pdf are not generated hourly (wait for the next devel release)
+run the normal lilypond-upload command, and (maybe) manually
+delete stuff you didn't want to upload from the server.
+@end enumerate
-VERSION-SPECIFIC MACROS
-- made with scripts/build/create-version-itexi.py
+@node Administrative policies
+@section Administrative policies
-- used extensively in the WEBSITE_ONLY_BUILD version of the
- website (made with website.make, and used on lilypond.org)
+Not really release-specific notes, but I don't see enough material
+here to make it a separate chapter, and the release person will
+probably be the one taking care of this anyway.
-- not (?) used in the main docs?
+@subsubheading Language-specific mailing lists
-- FIXME: the numbers in VERSION: MINOR should be 1 more than the
- last release, VERSION_DEVEL should be the last *online* release.
+A translator can ask for an official lilypond-xy mailing list once
+they've finished all @qq{priority 1} translation items.
+@subsubheading Performing yearly copyright update (@qq{grand-replace})
-LANGUAGE LISTS
+At the start of each year, copyright notices for all source files
+should be refreshed by running the following command from the top of
+the source tree:
-- a translator can ask for an official lilypond-xy mailing list
- once they've finished all "priority 1" translation items.
+@example
+make grand-replace
+@end example
+Internally, this invokes the script @file{scripts/build/grand-replace.py},
+which performs a regular expression substitution for old-year -> new-year
+wherever it finds a valid copyright notice.
+Note that snapshots of third party files such as @file{texinfo.tex} should
+not be included in the automatic update; @file{grand-replace.py} ignores these
+files if they are listed in the variable @code{copied_files}.