Doc: CG: put release info in correct places.

diff --git a/Documentation/contributor/compiling.itexi b/Documentation/contributor/compiling.itexi
index beaea040ef0d0580d8cac5d8863f4349e13f4ca1..04849b6c81e1967c9f634bd92b2196bd61625d48 100644 (file)
--- 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 52610d40332b22923419388bf54809b1ea1e5b5c..eba8b7639b3329afb176fb34e0f446139e52e5c4 100644 (file)
--- 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.