1 @c -*- coding: utf-8; mode: texinfo; -*-
7 * Minor release checklist::
8 * Major release checklist::
9 * Release extra notes::
10 * Administrative policies::
14 @node Development phases
15 @section Development phases
17 There are 2.5 states of development for LilyPond.
21 @item @strong{Stable phase}:
22 Starting from the release of a new major version @code{2.x.0}, the
23 following patches @strong{MAY NOT} be merged with master:
26 @item Any change to the input syntax. If a file compiled with a
27 previous @code{2.x} version, then it must compile in the new
30 @item New features with new syntax @emph{may be committed},
31 although once committed that syntax cannot change during the
32 remainder of the stable phase.
34 @item Any change to the build dependencies (including programming
35 libraries, documentation process programs, or python modules used
36 in the buildscripts). If a contributor could compile a previous
37 lilypond @code{2.x}, then he must be able to compile the new
42 @item @strong{Development phase}:
43 Any commits are fine. Readers may be familiar with the term
44 @qq{merge window} from following Linux kernel news.
47 @item @strong{Release prep phase}:
48 TODO: I don't like that name.
50 A new git branch @code{stable/2.x} is created, and a major release
55 @item @code{stable/2.x branch}:
56 Only translation updates and important bugfixes are allows.
59 Normal @qq{stable phase} development occurs.
63 If we discover the need to change the syntax or build system, we
64 will apply it and re-start the release prep phase.
68 This marks a radical change from previous practice in LilyPond.
69 However, this setup is not intended to slow development -- as a
70 rule of thumb, the next development phase will start within a
71 month of somebody wanting to commit something which is not
72 permitted during the stable phase.
76 @node Minor release checklist
77 @section Minor release checklist
79 A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
81 @subheading Pre-release
86 Switch to the release branch, get changes, prep release
90 git checkout release/unstable
92 vi Documentation/web/news-front.itexi Documentation/web/news.itexi
96 Commit, push, switch back to master:
99 git commit -m "Release: update news." Documentation/web/
103 @item (optional) Check that lilypond builds from scratch in an
107 If you do not have the previous release test-output tarball, download
108 it and put it in @code{regtests/}
110 @item Build release on GUB by running:
113 make LILYPOND_BRANCH=release/unstable lilypond
120 make LILYPOND_BRANCH=stable/2.12 lilypond
123 @item Check the regtest comparison in @file{uploads/webtest/} for
124 any unintentional breakage.
126 Note that this test uses the bounding boxes inside lilypond.
127 Errors in ghostscript don't generate differences inside lilypond,
128 so they are not registered in the regtest comparison.
130 @item If any work was done on GUB since the last release, upload
131 binaries to a temporary location, ask for feedback, and wait a day
132 or two in case there's any major problems.
137 @subheading Actual release
141 @item If you're not right user on the webserver, remove the "t"
142 from the rsync command in @file{test-lily/rsync-lily-doc.py} and
143 @file{test-lily/rsync-test.py}
145 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
147 @item Upload GUB by running:
150 make lilypond-upload LILYPOND_BRANCH=release/unstable LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
157 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
163 @subheading Post release
167 @item Switch back to master and get the updated news:
171 git merge release/unstable
174 @item Update @file{VERSION} in lilypond git and upload changes:
178 VERSION = what you just did +0.0.1
179 DEVEL_VERSION = what you just did (i.e. is now online)
180 STABLE_VERSION = what's online
186 git commit -m "Release: bump version." VERSION
191 @item (for now) do a @code{make doc} and manually upload:
194 ### upload-lily-web-media.sh
196 BUILD_DIR=$HOME/src/build-lilypond
198 PICS=$BUILD_DIR/Documentation/pictures/out-www/
199 EXAMPLES=$BUILD_DIR/Documentation/web/ly-examples/out-www/
202 rsync -a $PICS graham@@lilypond.org:media/pictures
203 rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
206 @item Wait a few hours for the website to update.
208 @item Email release notice to @code{info-lilypond}
214 @node Major release checklist
215 @section Major release checklist
217 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
219 - happens when we have 0 Critical issues for two weeks (14 days).
224 * write release notes. note: stringent size requirements for
225 various websites, so be brief.
227 * write preface section for manual.
229 * submit pots for translation : send url of tarball to
230 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
234 * Check all 2ly scripts.
236 * Run convert-ly on all files, bump parser minimum version.
238 * update links to distros providing lilypond packages? link in
239 Documentation/web/download.itexi . This has nothing to do with
240 the release, but I'm dumping this here so I'll find it when I
241 reorganize this list later. -gp
243 * Make FTP directories on lilypond.org
246 - Make new table in download.html
248 - add to documentation list
250 - revise examples tour.html/howto.html
252 - add to front-page quick links
254 - change all links to the stable documentation
256 - make a link from the old unstable to the next stable in
257 lilypond.org's /doc/ dir. Keep all previous unstable->stable
260 - doc auto redirects to v2.LATEST-STABLE
262 - add these two lines to http://www.lilypond.org/robots.txt:
265 Disallow: /doc/v2.PREVIOUS-STABLE/
266 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
269 - check for emergencies the docs:
272 grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
273 --exclude "snippets/*" ????*/*
276 - check for altered regtests, and document as necessary. (update
280 git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
287 comp.os.linux.announce
294 info-lilypond@@gnu.org
296 linux-audio-announce@@lists.linuxaudio.org
297 linux-audio-user@@lists.linuxaudio.org
298 linux-audio-dev@@lists.linuxaudio.org
300 tex-music@@icking-music-archive.org
303 abcusers@@blackmill.net
305 rosegarden-user@@lists.sourceforge.net
307 noteedit-user@@berlios.de
309 gmane.comp.audio.fomus.devel
310 gmane.linux.audio.users
311 gmane.linux.audio.announce
312 gmane.comp.audio.rosegarden.devel
319 http://www.apple.com/downloads
320 harmony-central.com (news@@harmony-central.com)
321 versiontracker.com [auto]
324 https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org
327 @node Release extra notes
328 @section Release extra notes
330 @subsubheading Regenerating regression tests
332 Regenerating regtests (if the lilypond-book naming has changed):
337 git checkout release/lilypond-X.Y.Z-A
340 take lilypond-book and any related makefile updates from the
344 - configure; make; make test
347 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
350 mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
361 @subsubheading stable/2.12
363 If releasing stable/2.12, then:
368 apply doc patch: patches/rsync-lily.patch (or something like
372 change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
373 to "lilypond-web.info"
376 @subsubheading Updating a release (changing a in x.y.z-a)
378 Really tentative instructions, almost certainly can be done
384 change the VERSION back to release you want. push change.
385 (hopefully you'll have forgotten to update it when you made your
389 make sure that there aren't any lilypond files floating around in
390 target/ (like usr/bin/lilypond).
393 build the specific package(s) you want, i.e.
396 bin/gub mingw::lilypond-installer
397 make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
398 bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
403 build everything with the normal "make lilypond", then (maybe)
404 manually delete stuff you don't want to upload.
407 manually upload them. good luck figuring out the rsync
408 command(s). Hints are in test-lily/
412 run the normal lilypond-upload command, and (maybe) manually
413 delete stuff you didn't want to upload from the server.
418 @node Administrative policies
419 @section Administrative policies
421 Not really release-specific notes, but I don't see enough material
422 here to make it a separate chapter, and the release person will
423 probably be the one taking care of this anyway.
425 @subsubheading Language-specific mailing lists
427 A translator can ask for an official lilypond-xy mailing list once
428 they've finished all @qq{priority 1} translation items.
430 @subsubheading Performing yearly copyright update (@qq{grand-replace})
432 At the start of each year, copyright notices for all source files
433 should be refreshed by running the following command from the top of
440 Internally, this invokes the script @file{scripts/build/grand-replace.py},
441 which performs a regular expression substitution for old-year -> new-year
442 wherever it finds a valid copyright notice.
444 Note that snapshots of third party files such as @file{texinfo.tex} should
445 not be included in the automatic update; @file{grand-replace.py} ignores these
446 files if they are listed in the variable @code{copied_files}.