Web build: separate htaccess files, add to security process.

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

diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi
index fa6575b49afa48ebfa206fc91a605d7902020445..929a09988699cc7545a8bb32c6273e2996ba4f2c 100644 (file)
--- a/Documentation/contributor/release-work.itexi
+++ b/Documentation/contributor/release-work.itexi
@@ -45,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.
@@ -83,37 +83,28 @@ A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
 @enumerate
 
 @item
-switch to the release branch:
+Switch to the release branch, get changes, prep release
+announcement:
 
 @example
 git checkout release/unstable
-@end example
-
-@item
-Get latest changes:
-
-@example
 git merge origin
+vi Documentation/web/news-front.itexi Documentation/web/news.itexi
 @end example
 
 @item
-Make a release announcement by adding a news item, and moving the
-oldest news item out of -front.
+Commit, push, switch back to master:
 
 @example
-Documentation/web/news-front.itexi
-Documentation/web/news.itexi
+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 Upload release branch.
-
-@example
-git push release/unstable
-@end example
-
 @item
 If you do not have the previous release test-output tarball, download
 it and put it in @code{regtests/}
@@ -121,7 +112,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
@@ -129,12 +120,15 @@ 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.
 
+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
 or two in case there's any major problems.
@@ -217,6 +211,9 @@ rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
 
 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
@@ -260,6 +257,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
@@ -406,5 +418,20 @@ probably be the one taking care of this anyway.
 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}.