X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fcontributor%2Frelease-work.itexi;h=146fcc45b788f0ff4b33be4bb555f05844f9125b;hb=218ed39bfe682e47cf92ca6abd365f8a41e91ae4;hp=8b8f88d22c74f519e99cb9b4b25d9ad8e1c97230;hpb=e343a09657b87891893a4cca13e6c1a3d775f34f;p=lilypond.git diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi index 8b8f88d22c..146fcc45b7 100644 --- a/Documentation/contributor/release-work.itexi +++ b/Documentation/contributor/release-work.itexi @@ -1,12 +1,13 @@ -@c -*- coding: us-ascii; mode: texinfo; -*- +@c -*- coding: utf-8; mode: texinfo; -*- @node Release work @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 @@ -44,7 +45,7 @@ Any commits are fine. Readers may be familiar with the term @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. @@ -81,10 +82,26 @@ A @qq{minor release} means an update of @code{y} in @code{2.x.y}. @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 +@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 @@ -93,7 +110,7 @@ it and put it in @code{regtests/} @item Build release on GUB by running: @example -make lilypond +make LILYPOND_BRANCH=release/unstable lilypond @end example @noindent @@ -103,15 +120,12 @@ or something like: 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 @@ -120,7 +134,7 @@ or two in case there's any major problems. @end enumerate -@subheading Post-release +@subheading Actual release @enumerate @@ -133,7 +147,7 @@ from the rsync command in @file{test-lily/rsync-lily-doc.py} and @item Upload GUB by running: @example -make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git +make lilypond-upload LILYPOND_BRANCH=release/unstable LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git @end example @noindent @@ -143,8 +157,51 @@ or something like: 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 and upload changes: -@item Update @file{VERSION} in lilypond git. +@quotation +@quotation +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 quotation +@end quotation + +@example +vi VERSION +git commit -m "Release: bump version." VERSION +git push origin +@end example + + +@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. @@ -153,11 +210,15 @@ make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv. @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 @@ -192,6 +253,10 @@ reorganize this list later. -gp - change all links to the stable documentation + - make a link from the old unstable to the next stable in + lilypond.org's /doc/ dir. Keep all previous unstable->stable + doc symlinks. + - doc auto redirects to v2.LATEST-STABLE - add these two lines to http://www.lilypond.org/robots.txt: @@ -201,6 +266,21 @@ Disallow: /doc/v2.PREVIOUS-STABLE/ 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 @@ -247,64 +327,120 @@ Web: @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/ + +@item +make lilypond + +@end itemize + + +@subsubheading stable/2.12 -- tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 - input/regression/out-test/ +If releasing stable/2.12, then: -- mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/ +@itemize -- cd ../gub/regtests/ +@item +apply doc patch: patches/rsync-lily.patch (or something like +that) -- make lilypond +@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) -New contributor idea: +Really tentative instructions, almost certainly can be done +better. -- tell them to spend 10 minutes on a problem, then give up and ask - for help +@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) -Latest website: +@item +make sure that there aren't any lilypond files floating around in +target/ (like usr/bin/lilypond). -- generated hourly on lilypond.org. Only split-HTML; big-html and - pdf are not generated hourly (wait for the next devel release) +@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 -VERSION-SPECIFIC MACROS +or -- made with scripts/build/create-version-itexi.py +build everything with the normal "make lilypond", then (maybe) +manually delete stuff you don't want to upload. -- used extensively in the WEBSITE_ONLY_BUILD version of the - website (made with website.make, and used on lilypond.org) +@item +manually upload them. good luck figuring out the rsync +command(s). Hints are in test-lily/ + +or + +run the normal lilypond-upload command, and (maybe) manually +delete stuff you didn't want to upload from the server. + +@end enumerate -- not (?) used in the main docs? -- FIXME: the numbers in VERSION: MINOR should be 1 more than the - last release, VERSION_DEVEL should be the last *online* release. +@node Administrative policies +@section Administrative policies +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. -LANGUAGE LISTS +@subsubheading Language-specific mailing lists -- a translator can ask for an official lilypond-xy mailing list - once they've finished all "priority 1" translation items. +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}) + +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: + +@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}.