]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/contributor/release-work.itexi
Merge branch 'master' into translation
[lilypond.git] / Documentation / contributor / release-work.itexi
index 10bf481b362020139b447833825b020483885e80..4828d1ae0ea348b461df37346347411e7177fb93 100644 (file)
 @node Development phases
 @section Development phases
 
-There are 2.5 states of development for LilyPond.
+There are 2 states of development on @code{master}:
 
-@itemize
+@enumerate
+
+@item @strong{Normal development}:
+Any commits are fine.
+
+@item @strong{Build-frozen}:
+Do not require any additional or updated libraries or make
+non-trivial changes to the build process.  Any such patch (or
+branch) may not be merged with master during this period.
+
+This should occur approximately 1 month before any alpha version
+of the next stable release, and ends when the next unstable branch
+begins.
+
+@end enumerate
 
-@item @strong{Stable phase}:
-Starting from the release of a new major version @code{2.x.0}, the
-following patches @strong{MAY NOT} be merged with master:
+
+After announcing a beta release, branch @code{stable/2.x}.  There
+are 2 states of development for this branch:
+
+@enumerate
+@item @strong{Normal maintenance}:
+The following patches @strong{MAY NOT} be merged with this branch:
 
 @itemize
 @item Any change to the input syntax.  If a file compiled with a
-previous @code{2.x} version, then it must compile in the new
-version.
+previous @code{2.x} (beta) version, then it must compile in the
+new version.
+
+Exception: any bugfix to a Critical issue.
 
 @item New features with new syntax @emph{may be committed},
 although once committed that syntax cannot change during the
@@ -38,38 +58,10 @@ version.
 
 @end itemize
 
-@item @strong{Development phase}:
-Any commits are fine.  Readers may be familiar with the term
-@qq{merge window} from following Linux kernel news.
-
-
-@item @strong{Release prep phase}:
-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.
-
-@itemize
-
-@item @code{stable/2.x branch}:
-Only translation updates and important bugfixes are allows.
-
-@item @code{master}:
-Normal @qq{stable phase} development occurs.
-
-@end itemize
-
-If we discover the need to change the syntax or build system, we
-will apply it and re-start the release prep phase.
-
-@end itemize
-
-This marks a radical change from previous practice in LilyPond.
-However, this setup is not intended to slow development -- as a
-rule of thumb, the next development phase will start within a
-month of somebody wanting to commit something which is not
-permitted during the stable phase.
+@item @strong{Release prep}:
+Only translation updates and important bugfixes are allowed.
 
+@end enumerate
 
 
 @node Minor release checklist
@@ -83,29 +75,53 @@ A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
 
 @item
 Switch to the release branch, get changes, prep release
-announcement:
+announcement.  This requires a clean index and work tree.  If the
+checkout displays modified files, you might want to run @code{git reset
+--hard} before continuing.
 
 @example
-git checkout release/unstable
+git fetch
+git checkout origin/release/unstable
 git merge origin
+make po-replace
 vi Documentation/web/news-front.itexi Documentation/web/news.itexi
 @end example
 
 @item
-Commit, push, switch back to master:
+Commit, push, switch back to master (or wherever else):
 
 @example
+git commit -m "PO: update template." po/lilypond.pot
 git commit -m "Release: update news." Documentation/web/
-git push origin
+git push origin HEAD:release/unstable
+git checkout master
 @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
 it and put it in @code{regtests/}
 
+@item Prepare GUB environment by running:
+
+@example
+### my-gub.sh
+# special terminal, and default PATH environment.
+# import these special environment vars:
+#   HOME, HTTP_PROXY, TERM
+env -i \
+  HOME=$HOME \
+  HTTP_PROXY=$HTTP_PROXY \
+  bash --rcfile my-bashrc
+@end example
+
+@example
+### my-bashrc
+export PS1="\[\e[1;33mGUB-ENV \w\]$ \[\e[0m\]"
+export PATH=$PATH
+export TERM=xterm
+@end example
+
+
 @item Build release on GUB by running:
 
 @example
@@ -119,15 +135,15 @@ or something like:
 make LILYPOND_BRANCH=stable/2.12 lilypond
 @end example
 
-@item Check the regtest comparison in @file{uploads/@/webtest/} for
+@item Check the regtest comparison in @file{uploads/webtest/} for
 any unintentional breakage.  More info in
-@ref{Precompiled regression tests}
+@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
-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.
+or two in case there's any major problems.
+
+@warning{Always do this for a stable release.}
 
 @end enumerate
 
@@ -136,23 +152,31 @@ dangerously, and don't tell anybody anything.
 
 @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}
+@item If you're not the right user on the webserver, remove the
+@code{t} from the rsync command in:
+
+@example
+test-lily/rsync-lily-doc.py
+test-lily/rsync-test.py
+@end example
 
 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
 
 @item Upload GUB by running:
 
 @example
-make lilypond-upload LILYPOND_BRANCH=release/unstable LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
+make lilypond-upload \
+  LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
+  LILYPOND_BRANCH=release/unstable
 @end example
 
 @noindent
 or something like:
 
 @example
-make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
+make lilypond-upload \
+  LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
+  LILYPOND_BRANCH=stable/2.12
 @end example
 
 @end enumerate
@@ -165,8 +189,8 @@ make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.
 @item Switch back to master and get the updated news:
 
 @example
-git checkout master
-git merge release/unstable
+git checkout origin/staging
+git merge origin/release/unstable
 @end example
 
 @item Update @file{VERSION} in lilypond git and upload changes:
@@ -189,7 +213,7 @@ STABLE_VERSION = what's online (probably no change here)
 
 @example
 git commit -m "Release: bump version." VERSION
-git push origin
+git push origin HEAD:staging
 @end example
 
 
@@ -201,7 +225,7 @@ git push origin
 BUILD_DIR=$HOME/src/build-lilypond
 
 PICS=$BUILD_DIR/Documentation/pictures/out-www/
-EXAMPLES=$BUILD_DIR/Documentation/web/ly-examples/out-www/
+EXAMPLES=$BUILD_DIR/Documentation/ly-examples/out-www/
 
 cd $BUILD_DIR
 rsync -a $PICS graham@@lilypond.org:media/pictures
@@ -221,112 +245,192 @@ 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).
+@subheading Main requirements
 
+This is the current official guidelines.
+
+@itemize
+@item
+0 Critical issues for two weeks (14 days) after the latest release
+candidate.
+
+@end itemize
 
-Before release:
 
-* write release notes. note: stringent size requirements for
- various websites, so be brief.
+@subheading Potential requirements
 
-* write preface section for manual.
+These might become official guidelines in the future.
+
+@itemize
+@item
+Check reg test
 
-* submit pots for translation : send url of tarball to
-translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
+@item
+Check all 2ly scripts
+
+@item
+Check for emergencies the docs:
+
+@example
+grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
+  --exclude "snippets/*" ????*/*
+@end example
 
-* Check reg test
+@item
+Check for altered regtests, and document as necessary.  (update
+numbers in the following command as appropriate)
 
-* Check all 2ly scripts.
+@example
+git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
+@end example
 
-* Run convert-ly on all files, bump parser minimum version.
+@end itemize
 
-* update links to distros providing lilypond packages?  link in
-Documentation/web/download.itexi .  This has nothing to do with
-the release, but I'm dumping this here so I'll find it when I
-reorganize this list later.  -gp
 
-* Make FTP directories on lilypond.org
+@subheading Housekeeping requirements
 
-* website:
-  - Make new table in download.html
+Before the release:
 
-  - add to documentation list
+@itemize
+@item
+write release notes.  note: stringent size requirements for
+various websites, so be brief.
 
-  - revise examples tour.html/howto.html
+@item
+Run convert-ly on all files, bump parser minimum version.
 
-  - add to front-page quick links
+@item
+Update lilypond.pot:
 
-  - change all links to the stable documentation
+@example
+make po-replace
+@end example
 
-  - make a link from the old unstable to the next stable in
-    lilypond.org's /doc/ dir.  Keep all previous unstable->stable
-    doc symlinks.
+@item
+Make directories on lilypond.org:
 
-  - doc auto redirects  to v2.LATEST-STABLE
+@example
+~/web/download/sources/v2.14
+~/web/download/sources/v2.15
+@end example
 
-  - add these two lines to http://www.lilypond.org/robots.txt:
+@item
+Shortly after the release, move all current contributors to
+previous contributors in:
 
 @example
-Disallow: /doc/v2.PREVIOUS-STABLE/
-Disallow: /doc/v2.CURRENT-DEVELOPMENT/
+Documentation/included/authors.itexi
 @end example
 
-- check for emergencies the docs:
+Also, delete old material in:
 
 @example
-grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
-  --exclude "snippets/*" ????*/*
+Documentation/changes.tely
 @end example
 
-- check for altered regtests, and document as necessary.  (update
-  tags as appropriate)
+but don't forget to check it still compiles!  also update the
+version numbers.
+
+@item
+Website:
+
+@itemize
+@item
+make a link from the old unstable to the next stable in
+lilypond.org's /doc/ dir.  Keep all previous unstable->stable doc
+symlinks.
+
+Also, make the old docs self-contained -- if there's a redirect in
+/doc/v2.12/Documentation/index.html , replace it with the
+index.html.old-2.12 files.
+
+The post-2.13 docs will need another way of handling the
+self-containment.  It won't be hard to whip up a python script
+that changes the link to ../../../../manuals.html to
+../website/manuals.html , but it's still a 30-minute task that
+needs to be done before 2.16.
+
+@item
+doc auto redirects  to v2.LATEST-STABLE
+
+@item
+add these two lines to http://www.lilypond.org/robots.txt:
 
 @example
-git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
+Disallow: /doc/v2.PREVIOUS-STABLE/
+Disallow: /doc/v2.CURRENT-DEVELOPMENT/
 @end example
 
+@end itemize
+
+@end itemize
+
+@subheading Unsorted
+
+@itemize
+@item
+submit po template for translation: send url of tarball to
+coordinator@@translationproject.org, mentioning lilypond-VERSION.pot
+
+@item
+update links to distros providing lilypond packages?  link in:
+@file{Documentation/web/download.itexi}
+
+This has nothing to do with the release, but it's a "periodic
+maintenance" task that might make sense to include with releases.
+
+@item
+Send announcements to...
 
 News:
 
-        comp.music.research
-        comp.os.linux.announce
+@example
+comp.music.research
+comp.os.linux.announce
 
-        comp.text.tex
-        rec.music.compose
+comp.text.tex
+rec.music.compose
+@end example
 
 Mail:
 
-        info-lilypond@@gnu.org
+@example
+info-lilypond@@gnu.org
 
 linux-audio-announce@@lists.linuxaudio.org
 linux-audio-user@@lists.linuxaudio.org
 linux-audio-dev@@lists.linuxaudio.org
 
-        tex-music@@icking-music-archive.org
+tex-music@@icking-music-archive.org
 
-   --- non-existant?
-        abcusers@@blackmill.net
+--- non-existant?
+abcusers@@blackmill.net
 
-        rosegarden-user@@lists.sourceforge.net
-        info-gnu@@gnu.org
-        noteedit-user@@berlios.de
+rosegarden-user@@lists.sourceforge.net
+info-gnu@@gnu.org
+noteedit-user@@berlios.de
 
-        gmane.comp.audio.fomus.devel
-        gmane.linux.audio.users
-        gmane.linux.audio.announce
-        gmane.comp.audio.rosegarden.devel
+gmane.comp.audio.fomus.devel
+gmane.linux.audio.users
+gmane.linux.audio.announce
+gmane.comp.audio.rosegarden.devel
+@end example
 
 Web:
 
-        lilypond.org
-        freshmeat.net
-        linuxfr.com
-        http://www.apple.com/downloads
-        harmony-central.com (news@@harmony-central.com)
-        versiontracker.com [auto]
-        hitsquad.com [auto]
-        http://www.svgx.org
-        https://savannah.gnu.org/news/submit.php?group_id=1673  @c => planet.gnu.org
+@example
+lilypond.org
+freshmeat.net
+linuxfr.com
+http://www.apple.com/downloads
+harmony-central.com (news@@harmony-central.com)
+versiontracker.com [auto]
+hitsquad.com [auto]
+http://www.svgx.org
+https://savannah.gnu.org/news/submit.php?group_id=1673  @c => planet.gnu.org
+@end example
+
+@end itemize
 
 
 @node Release extra notes
@@ -346,7 +450,7 @@ take lilypond-book and any related makefile updates from the
 latest git.
 
 @item
-configure; make; make test
+configure; make; make test
 
 @item
 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
@@ -400,7 +504,8 @@ 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 --platform=darwin-x86 \
+  'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
 @end example
 
 or