From: Graham Percival Date: Mon, 18 Jan 2010 13:32:08 +0000 (+0000) Subject: Doc: CG: put release info in correct places. X-Git-Tag: release/2.13.12-1~106 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=1aaf879de5009d5f1099960375dace171fe36a3a;p=lilypond.git Doc: CG: put release info in correct places. --- diff --git a/Documentation/contributor/compiling.itexi b/Documentation/contributor/compiling.itexi index beaea040ef..04849b6c81 100644 --- a/Documentation/contributor/compiling.itexi +++ b/Documentation/contributor/compiling.itexi @@ -7,6 +7,7 @@ * Compiling from source:: * Concurrent Stable and Development Versions:: * Using a Virtual Machine to Compile LilyPond:: +* Build system:: @end menu @node Compiling from source @@ -166,3 +167,36 @@ At this point everything has been compiled. You may install Lilypond using @code{make install}, or you may wish to set up your system with concurrent stable and development versions as described in the previous section. + + +@node Build system +@section Build system + +We currently use make and stepmake, which is complicated and only +used by us. Hopefully this will change in the future. + + +@subsubheading Version-specific texinfo macors + +@itemize + +@item +made with @command{scripts/build/create-version-itexi.py} and +@command{scripts/build/create-weblinks-itexi.py} + +@item +used extensively in the @code{WEBSITE_ONLY_BUILD} version of the +website (made with website.make, used on lilypond.org) + +@item +not (?) used in the main docs? + +@item +the numbers in VERSION file: MINOR_VERSION should be 1 more than +the last release, VERSION_DEVEL should be the last @strong{online} +release. Yes, VERSION_DEVEL is less than VERSION. + +@end itemize + + + diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi index 52610d4033..eba8b7639b 100644 --- a/Documentation/contributor/release-work.itexi +++ b/Documentation/contributor/release-work.itexi @@ -3,10 +3,11 @@ @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 @@ -81,10 +82,37 @@ 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: + +@example +git checkout release/unstable +@end example + +@item +Get latest changes: + +@example +git merge origin +@end example + +@item +Make a release announcement by adding a news item, and moving the +oldest news item out of -front. + +@example +Documentation/web/news-front.itexi +Documentation/web/news.itexi +@end example + +@item (optional) Check that lilypond builds from scratch in an +out-of-tree build. -@item Check that lilypond builds from scratch in an out-of-tree -build. +@item Upload release branch. + +@example +git push release/unstable +@end example @item If you do not have the previous release test-output tarball, download @@ -101,18 +129,12 @@ or something like: @example make LILYPOND_BRANCH=stable/2.12 lilypond +make LILYPOND_BRANCH=release/unstable 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} - @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. @@ -120,7 +142,7 @@ or two in case there's any major problems. @end enumerate -@subheading Post-release +@subheading Actual release @enumerate @@ -143,8 +165,44 @@ 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: + +@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/ -@item Update @file{VERSION} in lilypond git. +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,6 +211,7 @@ make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv. @end enumerate + @node Major release checklist @section Major release checklist @@ -247,115 +306,104 @@ Web: @node Release extra notes @section Release extra notes -If releasing stable/2.12, then: - -- apply doc patch: patches/rsync-lily.patch (or something like - that) - -- change infodir in gub/specs/lilypond-doc.py from "lilypond.info" - to "lilypond-web.info" - - -GENERAL STUFF TO BE MOVED ELSEWHERE +@subsubheading Regenerating regression tests Regenerating regtests (if the lilypond-book naming has changed): -- git checkout release/lilypond-X.Y.Z-A - -- take lilypond-book and any related makefile updates from the - latest git. - -- configure; make; make test +@itemize -- tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 - input/regression/out-test/ +@item +git checkout release/lilypond-X.Y.Z-A -- mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/ +@item +take lilypond-book and any related makefile updates from the +latest git. -- cd ../gub/regtests/ +@item +- configure; make; make test -- make lilypond +@item +tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/ +@item +mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/ +@item +cd ../gub/regtests/ -VERSION-SPECIFIC MACROS +@item +make lilypond -- made with scripts/build/create-version-itexi.py +@end itemize -- used extensively in the WEBSITE_ONLY_BUILD version of the - website (made with website.make, and used on lilypond.org) -- not (?) used in the main docs? +@subsubheading stable/2.12 -- FIXME: the numbers in VERSION: MINOR should be 1 more than the - last release, VERSION_DEVEL should be the last *online* release. +If releasing stable/2.12, then: +@itemize -LANGUAGE LISTS +@item +apply doc patch: patches/rsync-lily.patch (or something like +that) -- a translator can ask for an official lilypond-xy mailing list - once they've finished all "priority 1" translation items. +@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) -UPDATING A RELEASE ( x.y.z-a, where a>1 ) +Really tentative instructions, almost certainly can be done +better. -really tentative instructions, almost certainly can be done better +@enumerate -1. change the VERSION back to release you want. push change. +@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) -2. make sure that there aren't any lilypond files floating around -in target/ (like usr/bin/lilypond). +@item +make sure that there aren't any lilypond files floating around in +target/ (like usr/bin/lilypond). -3. build the specific package(s) you want, i.e. +@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 -4. manually upload them. good luck figuring out the rsync -command(s). Hints are in test-lily/ - - -MAKING A RELEASE -- NEW INFO - -(wow, I really need to stop being so messy here. Will clean it up -after 2.13.11; I need a chance to test these instructions) +or -1. switch to the release branch: - git checkout release/unstable +build everything with the normal "make lilypond", then (maybe) +manually delete stuff you don't want to upload. -1b. get latest changes - git merge origin +@item +manually upload them. good luck figuring out the rsync +command(s). Hints are in test-lily/ -2. make a release announcement by editing: - Documentation/web/news-front.itexi - Documentation/web/news.itexi -(moving the oldest news item to news-old.itexi) +or -3. upload: - git push release/unstable +run the normal lilypond-upload command, and (maybe) manually +delete stuff you didn't want to upload from the server. -4. make GUB as "normal" - make LILYPOND_BRANCH=release/unstable lilypond -(if this works, make it the default for GUB) +@end enumerate -5. upload git, etc. -6. switch back to master and get the updated news: - git checkout master - git merge release/unstable +@node Administrative policies +@section Administrative policies -7. update VERSION, commit, push. - VERSION = what you just did +0.0.1 - DEVEL_VERSION = what you just did (i.e. is now online) - STABLE_VERSION = what's online +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. +@subsubheading Language-specific mailing lists -8. (for now) manually upload - Documentation/pictures/out-www/ - Documentation/web/ly-examples/out-www/ -to $HOME/media/pictures .../ly-examples on lilypond.org +A translator can ask for an official lilypond-xy mailing list once +they've finished all @qq{priority 1} translation items.