1 @c -*- coding: utf-8; mode: texinfo; -*-
7 * Minor release checklist::
8 * Major release checklist::
9 * Release extra notes::
13 @node Development phases
14 @section Development phases
16 There are 2 states of development on @code{master}:
20 @item @strong{Normal development}:
23 @item @strong{Build-frozen}:
24 Do not require any additional or updated libraries or make
25 non-trivial changes to the build process. Any such patch (or
26 branch) may not be merged with master during this period.
28 This should occur approximately 1 month before any alpha version
29 of the next stable release, and ends when the next unstable branch
35 After announcing a beta release, branch @code{stable/2.x}. There
36 are 2 states of development for this branch:
39 @item @strong{Normal maintenance}:
40 The following patches @strong{MAY NOT} be merged with this branch:
43 @item Any change to the input syntax. If a file compiled with a
44 previous @code{2.x} (beta) version, then it must compile in the
47 Exception: any bugfix to a Critical issue.
49 @item New features with new syntax @emph{may be committed},
50 although once committed that syntax cannot change during the
51 remainder of the stable phase.
53 @item Any change to the build dependencies (including programming
54 libraries, documentation process programs, or python modules used
55 in the buildscripts). If a contributor could compile a previous
56 lilypond @code{2.x}, then he must be able to compile the new
61 @item @strong{Release prep}:
62 Only translation updates and important bugfixes are allowed.
67 @node Minor release checklist
68 @section Minor release checklist
70 A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
72 @subheading Pre-release
77 Switch to the release branch, get changes, prep release
78 announcement. This requires a clean index and work tree. If the
79 checkout displays modified files, you might want to run @code{git reset
80 --hard} before continuing.
84 git checkout origin/release/unstable
86 make -C /path/to/top-build-dir po-replace
87 mv /path/to/top-build-dir/po/lilypond.pot po/
88 vi Documentation/web/news-front.itexi Documentation/web/news.itexi
92 Commit, push, switch back to master (or wherever else):
95 git commit -m "PO: update template." po/lilypond.pot
96 git commit -m "Release: update news." Documentation/web/
97 git push origin HEAD:release/unstable
102 If you do not have the previous release test-output tarball, download
103 it and put it in @code{regtests/}
105 @item Prepare GUB environment by running:
109 # special terminal, and default PATH environment.
110 # import these special environment vars:
111 # HOME, HTTP_PROXY, TERM
114 HTTP_PROXY=$HTTP_PROXY \
115 bash --rcfile my-bashrc
120 export PS1="\[\e[1;33mGUB-ENV \w\]$ \[\e[0m\]"
126 @item Build release on GUB by running:
129 make LILYPOND_BRANCH=release/unstable lilypond
136 make LILYPOND_BRANCH=stable/2.12 lilypond
139 @item Check the regtest comparison in @file{uploads/webtest/} for
140 any unintentional breakage. More info in
141 @ref{Precompiled regression tests}.
143 @item If any work was done on GUB since the last release, upload
144 binaries to a temporary location, ask for feedback, and wait a day
145 or two in case there's any major problems.
147 @warning{Always do this for a stable release.}
152 @subheading Actual release
156 @item If you're not the right user on the webserver, remove the
157 @code{t} from the rsync command in:
160 test-lily/rsync-lily-doc.py
161 test-lily/rsync-test.py
164 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
166 @item Upload GUB by running:
169 make lilypond-upload \
170 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
171 LILYPOND_BRANCH=release/unstable
178 make lilypond-upload \
179 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
180 LILYPOND_BRANCH=stable/2.12
186 @subheading Post release
190 @item Update the current staging branch with the current news:
194 git checkout origin/staging
195 git merge origin/release/unstable
198 @item Update @file{VERSION} in lilypond git and upload changes:
206 VERSION = what you just did +0.0.1
209 DEVEL_VERSION = what you just did (i.e. is now online)
212 STABLE_VERSION = what's online (probably no change here)
217 git commit -m "Release: bump version." VERSION
218 git push origin HEAD:staging
221 If the push fails with a message like
224 ! [rejected] HEAD -> staging (non-fast-forward)
228 it means that somebody else updated the staging branch while you were
229 preparing your change. In that case, you need to restart the Post
230 Release process. Otherwise, proceed:
232 @item (for now) do a @code{make doc} and manually upload:
235 ### upload-lily-web-media.sh
237 BUILD_DIR=$HOME/src/build-lilypond
239 PICS=$BUILD_DIR/Documentation/pictures/out-www/
240 EXAMPLES=$BUILD_DIR/Documentation/ly-examples/out-www/
243 rsync -a $PICS graham@@lilypond.org:media/pictures
244 rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
247 @item Wait a few hours for the website to update.
249 @item Email release notice to @code{info-lilypond}
255 @node Major release checklist
256 @section Major release checklist
258 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
260 @subheading Main requirements
262 This is the current official guidelines.
266 0 Critical issues for two weeks (14 days) after the latest release
272 @subheading Potential requirements
274 These might become official guidelines in the future.
281 Check all 2ly scripts
284 Check for emergencies the docs:
287 grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
288 --exclude "snippets/*" ????*/*
292 Check for altered regtests, and document as necessary. (update
293 numbers in the following command as appropriate)
296 git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
302 @subheading Housekeeping requirements
308 write release notes. note: stringent size requirements for
309 various websites, so be brief.
312 Run convert-ly on all files, bump parser minimum version.
320 If you run this outside the source tree, move @file{po/lilypond.pot}
324 Make directories on lilypond.org:
327 ~/web/download/sources/v2.14
328 ~/web/download/sources/v2.15
332 Shortly after the release, move all current contributors to
333 previous contributors in:
336 Documentation/included/authors.itexi
339 Also, delete old material in:
342 Documentation/changes.tely
345 but don't forget to check it still compiles! also update the
353 make a link from the old unstable to the next stable in
354 lilypond.org's /doc/ dir. Keep all previous unstable->stable doc
357 Also, make the old docs self-contained -- if there's a redirect in
358 /doc/v2.12/Documentation/index.html , replace it with the
359 index.html.old-2.12 files.
361 The post-2.13 docs will need another way of handling the
362 self-containment. It won't be hard to whip up a python script
363 that changes the link to ../../../../manuals.html to
364 ../website/manuals.html , but it's still a 30-minute task that
365 needs to be done before 2.16.
368 doc auto redirects to v2.LATEST-STABLE
371 add these two lines to http://www.lilypond.org/robots.txt:
374 Disallow: /doc/v2.PREVIOUS-STABLE/
375 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
386 submit po template for translation: send url of tarball to
387 coordinator@@translationproject.org, mentioning lilypond-VERSION.pot
390 update links to distros providing lilypond packages? link in:
391 @file{Documentation/web/download.itexi}
393 This has nothing to do with the release, but it's a "periodic
394 maintenance" task that might make sense to include with releases.
397 Send announcements to...
403 comp.os.linux.announce
412 info-lilypond@@gnu.org
414 linux-audio-announce@@lists.linuxaudio.org
415 linux-audio-user@@lists.linuxaudio.org
416 linux-audio-dev@@lists.linuxaudio.org
418 tex-music@@icking-music-archive.org
421 abcusers@@blackmill.net
423 rosegarden-user@@lists.sourceforge.net
425 noteedit-user@@berlios.de
427 gmane.comp.audio.fomus.devel
428 gmane.linux.audio.users
429 gmane.linux.audio.announce
430 gmane.comp.audio.rosegarden.devel
439 http://www.apple.com/downloads
440 harmony-central.com (news@@harmony-central.com)
441 versiontracker.com [auto]
444 https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org
450 @node Release extra notes
451 @section Release extra notes
453 @subsubheading Regenerating regression tests
455 Regenerating regtests (if the lilypond-book naming has changed):
460 git checkout release/lilypond-X.Y.Z-A
463 take lilypond-book and any related makefile updates from the
467 configure; make; make test
470 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
473 mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
484 @subsubheading stable/2.12
486 If releasing stable/2.12, then:
491 apply doc patch: patches/rsync-lily.patch (or something like
495 change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
496 to "lilypond-web.info"
499 @subsubheading Updating a release (changing a in x.y.z-a)
501 Really tentative instructions, almost certainly can be done
507 change the VERSION back to release you want. push change.
508 (hopefully you'll have forgotten to update it when you made your
512 make sure that there aren't any lilypond files floating around in
513 target/ (like usr/bin/lilypond).
516 build the specific package(s) you want, i.e.
519 bin/gub mingw::lilypond-installer
520 make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
521 bin/gub --platform=darwin-x86 \
522 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
527 build everything with the normal "make lilypond", then (maybe)
528 manually delete stuff you don't want to upload.
531 manually upload them. good luck figuring out the rsync
532 command(s). Hints are in test-lily/
536 run the normal lilypond-upload command, and (maybe) manually
537 delete stuff you didn't want to upload from the server.