X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fcontributor%2Frelease-work.itexi;h=b1a79e477fd0ce5fcbf4960055a613c2260f3797;hb=42c861fae113f268785428586c1ed746ddb9f4e7;hp=3c62f672613f432d2c179c7a4fa21fbf2fcabdd9;hpb=87aec4a93a0fe08275dd6cce6961dd9f80f581d1;p=lilypond.git diff --git a/Documentation/contributor/release-work.itexi b/Documentation/contributor/release-work.itexi index 3c62f67261..b1a79e477f 100644 --- a/Documentation/contributor/release-work.itexi +++ b/Documentation/contributor/release-work.itexi @@ -7,7 +7,6 @@ * Minor release checklist:: * Major release checklist:: * Release extra notes:: -* Administrative policies:: @end menu @@ -45,7 +44,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. @@ -92,15 +91,17 @@ git merge origin vi 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 Upload release branch. +@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 it and put it in @code{regtests/} @@ -118,12 +119,15 @@ or something like: make LILYPOND_BRANCH=stable/2.12 lilypond @end example -@item Check the regtest comparison in @file{uploads/webtest/} for -any unintentional breakage. +@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 -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 @@ -133,15 +137,15 @@ or two in case there's any major problems. @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 -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 @@ -165,15 +169,29 @@ git checkout master git merge release/unstable @end example -@item Update @file{VERSION} in lilypond git: +@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) -STABLE_VERSION = what's 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 Push changes. @item (for now) do a @code{make doc} and manually upload: @@ -203,6 +221,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 @@ -210,7 +231,7 @@ Before release: * 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 @@ -237,6 +258,10 @@ reorganize this list later. -gp - 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: @@ -246,6 +271,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 @@ -380,32 +420,4 @@ delete stuff you didn't want to upload from the server. @end enumerate -@node Administrative policies -@section Administrative policies - -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 - -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}.