* Minor release checklist::
* Major release checklist::
* Release extra notes::
-* Administrative policies::
@end menu
@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.
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/}
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
@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
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:
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
+* write release notes. note: stringent size requirements for
various websites, so be brief.
* 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
- 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:
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
@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}.
projects / lilypond.git / blobdiff