Doc: fix period and colon placement in a couple of instances.

[lilypond.git] / Documentation / contributor / release-work.itexi

diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi
index 209b877c2feb65396c79ebef28e251a532b05c72..b1a79e477fd0ce5fcbf4960055a613c2260f3797 100644 (file)
--- a/Documentation/contributor/release-work.itexi
+++ b/Documentation/contributor/release-work.itexi
@@ -3,10 +3,10 @@
 @chapter Release work
 
 @menu
 @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::

 @end menu
 
 
 @end menu
 
 


@@ -44,7 +44,7 @@ Any commits are fine.  Readers may be familiar with the term
 
 
 @item @strong{Release prep phase}:
 
 
 @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.
 
 A new git branch @code{stable/2.x} is created, and a major release
 is made in two weeks.


@@ -81,10 +81,26 @@ A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
 
 @enumerate
 
 
 @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
 
 @item
 If you do not have the previous release test-output tarball, download


@@ -93,7 +109,7 @@ it and put it in @code{regtests/}
 @item Build release on GUB by running:
 
 @example
 @item Build release on GUB by running:
 
 @example

-make lilypond
+make LILYPOND_BRANCH=release/unstable lilypond

 @end example
 
 @noindent
 @end example
 
 @noindent


@@ -103,37 +119,33 @@ or something like:
 make LILYPOND_BRANCH=stable/2.12 lilypond
 @end example
 
 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}
+@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
 binaries to a temporary location, ask for feedback, and wait a day
 
 @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.
+or two in case there's any major problems.  Or live dangerously
+and just add a sentence to the release notes.  Or live even more
+dangerously, and don't tell anybody anything.

 
 @end enumerate
 
 
 
 @end enumerate
 
 

-@subheading Post-release
+@subheading Actual release

 
 @enumerate
 
 @item If you're not right user on the webserver, remove the "t"
 
 @enumerate
 
 @item If you're not right user on the webserver, remove the "t"

-from the rsync command in @file{test-lily/rsync-lily-doc.py} and
-@file{test-lily/rsync-test.py}
+from the rsync command in @file{test@/-lily/@/rsync@/-lily@/-doc@/.py} and
+@file{test@/-lily/@/rsync@/-test@/.py}

 
 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
 
 @item Upload GUB by running:
 
 @example
 
 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
 
 @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
 @end example
 
 @noindent


@@ -143,8 +155,58 @@ or something like:
 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
 @end example
 
 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:

 
 

-@item Update @file{VERSION} in lilypond git.
+@example
+git checkout master
+git merge release/unstable
+@end example
+
+@item Update @file{VERSION} in lilypond git and upload changes:
+
+@example
+vi 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 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.
 
 
 @item Wait a few hours for the website to update.
 


@@ -153,11 +215,15 @@ make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.
 @end enumerate
 
 
 @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}.
 
 @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
 Before release:
 
 * write release notes. note: stringent size requirements for


@@ -165,7 +231,7 @@ Before release:
 
 * write preface section for manual.
 
 
 * write preface section for manual.
 

-* submit pots for translation : send url of tarball to
+* submit pots for translation: send url of tarball to

 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
 
 * Check reg test
 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
 
 * Check reg test


@@ -192,6 +258,10 @@ reorganize this list later.  -gp
 
   - change all links to the stable documentation
 
 
   - 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:
   - doc auto redirects  to v2.LATEST-STABLE
 
   - add these two lines to http://www.lilypond.org/robots.txt:


@@ -201,6 +271,21 @@ Disallow: /doc/v2.PREVIOUS-STABLE/
 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
 @end example
 
 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
 News:
 
         comp.music.research


@@ -247,115 +332,92 @@ Web:
 @node Release extra notes
 @section Release extra notes
 
 @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):
 
 
 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)
 
 (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'
 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)
-
-1. switch to the release branch:
-  git checkout release/unstable
-
-1b. get latest changes
-  git merge origin
-
-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)
-
-3. upload:
-  git push release/unstable
+or

 
 

-4. make GUB as "normal"
-  make LILYPOND_BRANCH=release/unstable lilypond
-(if this works, make it the default for GUB)
+build everything with the normal "make lilypond", then (maybe)
+manually delete stuff you don't want to upload.

 
 

-5. upload git, etc.
+@item
+manually upload them.  good luck figuring out the rsync
+command(s).  Hints are in test-lily/

 
 

-6. switch back to master and get the updated news:
-  git checkout master
-  git merge origin/release/unstable
+or

 
 

-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
+run the normal lilypond-upload command, and (maybe) manually
+delete stuff you didn't want to upload from the server.

 
 

+@end enumerate

 
 

-8. (for now)  manually upload
-  Documentation/pictures/out-www/
-  Documentation/web/ly-examples/out-www/
-to $HOME/media/pictures .../ly-examples on lilypond.org