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 FIXME: 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:
89 git checkout release/unstable
100 Make a release announcement by adding a news item, and moving the
101 oldest news item out of -front.
104 Documentation/web/news-front.itexi
105 Documentation/web/news.itexi
108 @item (optional) Check that lilypond builds from scratch in an
111 @item Upload release branch.
114 git push release/unstable
118 If you do not have the previous release test-output tarball, download
119 it and put it in @code{regtests/}
121 @item Build release on GUB by running:
131 make LILYPOND_BRANCH=stable/2.12 lilypond
132 make LILYPOND_BRANCH=release/unstable lilypond
135 @item Check the regtest comparison in @file{uploads/webtest/} for
136 any unintentional breakage.
138 @item If any work was done on GUB since the last release, upload
139 binaries to a temporary location, ask for feedback, and wait a day
140 or two in case there's any major problems.
145 @subheading Actual release
149 @item If you're not right user on the webserver, remove the "t"
150 from the rsync command in @file{test-lily/rsync-lily-doc.py} and
151 @file{test-lily/rsync-test.py}
153 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
155 @item Upload GUB by running:
158 make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
165 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
171 @subheading Post release
175 @item Switch back to master and get the updated news:
179 git merge release/unstable
182 @item Update @file{VERSION} in lilypond git:
185 VERSION = what you just did +0.0.1
186 DEVEL_VERSION = what you just did (i.e. is now online)
187 STABLE_VERSION = what's online
192 @item (for now) do a @code{make doc} and manually upload:
195 ### upload-lily-web-media.sh
197 BUILD_DIR=$HOME/src/build-lilypond
199 PICS=$BUILD_DIR/Documentation/pictures/out-www/
200 EXAMPLES=$BUILD_DIR/Documentation/web/ly-examples/out-www/
203 rsync -a $PICS graham@@lilypond.org:media/pictures
204 rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
207 @item Wait a few hours for the website to update.
209 @item Email release notice to @code{info-lilypond}
215 @node Major release checklist
216 @section Major release checklist
218 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
222 * write release notes. note: stringent size requirements for
223 various websites, so be brief.
225 * write preface section for manual.
227 * submit pots for translation : send url of tarball to
228 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
232 * Check all 2ly scripts.
234 * Run convert-ly on all files, bump parser minimum version.
236 * update links to distros providing lilypond packages? link in
237 Documentation/web/download.itexi . This has nothing to do with
238 the release, but I'm dumping this here so I'll find it when I
239 reorganize this list later. -gp
241 * Make FTP directories on lilypond.org
244 - Make new table in download.html
246 - add to documentation list
248 - revise examples tour.html/howto.html
250 - add to front-page quick links
252 - change all links to the stable documentation
254 - doc auto redirects to v2.LATEST-STABLE
256 - add these two lines to http://www.lilypond.org/robots.txt:
259 Disallow: /doc/v2.PREVIOUS-STABLE/
260 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
266 comp.os.linux.announce
273 info-lilypond@@gnu.org
275 linux-audio-announce@@lists.linuxaudio.org
276 linux-audio-user@@lists.linuxaudio.org
277 linux-audio-dev@@lists.linuxaudio.org
279 tex-music@@icking-music-archive.org
282 abcusers@@blackmill.net
284 rosegarden-user@@lists.sourceforge.net
286 noteedit-user@@berlios.de
288 gmane.comp.audio.fomus.devel
289 gmane.linux.audio.users
290 gmane.linux.audio.announce
291 gmane.comp.audio.rosegarden.devel
298 http://www.apple.com/downloads
299 harmony-central.com (news@@harmony-central.com)
300 versiontracker.com [auto]
303 https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org
306 @node Release extra notes
307 @section Release extra notes
309 @subsubheading Regenerating regression tests
311 Regenerating regtests (if the lilypond-book naming has changed):
316 git checkout release/lilypond-X.Y.Z-A
319 take lilypond-book and any related makefile updates from the
323 - configure; make; make test
326 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
329 mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
340 @subsubheading stable/2.12
342 If releasing stable/2.12, then:
347 apply doc patch: patches/rsync-lily.patch (or something like
351 change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
352 to "lilypond-web.info"
355 @subsubheading Updating a release (changing a in x.y.z-a)
357 Really tentative instructions, almost certainly can be done
363 change the VERSION back to release you want. push change.
364 (hopefully you'll have forgotten to update it when you made your
368 make sure that there aren't any lilypond files floating around in
369 target/ (like usr/bin/lilypond).
372 build the specific package(s) you want, i.e.
375 bin/gub mingw::lilypond-installer
376 make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
377 bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
382 build everything with the normal "make lilypond", then (maybe)
383 manually delete stuff you don't want to upload.
386 manually upload them. good luck figuring out the rsync
387 command(s). Hints are in test-lily/
391 run the normal lilypond-upload command, and (maybe) manually
392 delete stuff you didn't want to upload from the server.
397 @node Administrative policies
398 @section Administrative policies
400 Not really release-specific notes, but I don't see enough material
401 here to make it a separate chapter, and the release person will
402 probably be the one taking care of this anyway.
404 @subsubheading Language-specific mailing lists
406 A translator can ask for an official lilypond-xy mailing list once
407 they've finished all @qq{priority 1} translation items.