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, get changes, prep release
90 git checkout release/unstable
92 vi Documentation/web/news-front.itexi Documentation/web/news.itexi
95 @item (optional) Check that lilypond builds from scratch in an
98 @item Upload release branch.
105 If you do not have the previous release test-output tarball, download
106 it and put it in @code{regtests/}
108 @item Build release on GUB by running:
111 make LILYPOND_BRANCH=release/unstable lilypond
118 make LILYPOND_BRANCH=stable/2.12 lilypond
121 @item Check the regtest comparison in @file{uploads/webtest/} for
122 any unintentional breakage.
124 @item If any work was done on GUB since the last release, upload
125 binaries to a temporary location, ask for feedback, and wait a day
126 or two in case there's any major problems.
131 @subheading Actual release
135 @item If you're not right user on the webserver, remove the "t"
136 from the rsync command in @file{test-lily/rsync-lily-doc.py} and
137 @file{test-lily/rsync-test.py}
139 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
141 @item Upload GUB by running:
144 make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
151 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
157 @subheading Post release
161 @item Switch back to master and get the updated news:
165 git merge release/unstable
168 @item Update @file{VERSION} in lilypond git:
171 VERSION = what you just did +0.0.1
172 DEVEL_VERSION = what you just did (i.e. is now online)
173 STABLE_VERSION = what's online
178 @item (for now) do a @code{make doc} and manually upload:
181 ### upload-lily-web-media.sh
183 BUILD_DIR=$HOME/src/build-lilypond
185 PICS=$BUILD_DIR/Documentation/pictures/out-www/
186 EXAMPLES=$BUILD_DIR/Documentation/web/ly-examples/out-www/
189 rsync -a $PICS graham@@lilypond.org:media/pictures
190 rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
193 @item Wait a few hours for the website to update.
195 @item Email release notice to @code{info-lilypond}
201 @node Major release checklist
202 @section Major release checklist
204 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
208 * write release notes. note: stringent size requirements for
209 various websites, so be brief.
211 * write preface section for manual.
213 * submit pots for translation : send url of tarball to
214 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
218 * Check all 2ly scripts.
220 * Run convert-ly on all files, bump parser minimum version.
222 * update links to distros providing lilypond packages? link in
223 Documentation/web/download.itexi . This has nothing to do with
224 the release, but I'm dumping this here so I'll find it when I
225 reorganize this list later. -gp
227 * Make FTP directories on lilypond.org
230 - Make new table in download.html
232 - add to documentation list
234 - revise examples tour.html/howto.html
236 - add to front-page quick links
238 - change all links to the stable documentation
240 - doc auto redirects to v2.LATEST-STABLE
242 - add these two lines to http://www.lilypond.org/robots.txt:
245 Disallow: /doc/v2.PREVIOUS-STABLE/
246 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
252 comp.os.linux.announce
259 info-lilypond@@gnu.org
261 linux-audio-announce@@lists.linuxaudio.org
262 linux-audio-user@@lists.linuxaudio.org
263 linux-audio-dev@@lists.linuxaudio.org
265 tex-music@@icking-music-archive.org
268 abcusers@@blackmill.net
270 rosegarden-user@@lists.sourceforge.net
272 noteedit-user@@berlios.de
274 gmane.comp.audio.fomus.devel
275 gmane.linux.audio.users
276 gmane.linux.audio.announce
277 gmane.comp.audio.rosegarden.devel
284 http://www.apple.com/downloads
285 harmony-central.com (news@@harmony-central.com)
286 versiontracker.com [auto]
289 https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org
292 @node Release extra notes
293 @section Release extra notes
295 @subsubheading Regenerating regression tests
297 Regenerating regtests (if the lilypond-book naming has changed):
302 git checkout release/lilypond-X.Y.Z-A
305 take lilypond-book and any related makefile updates from the
309 - configure; make; make test
312 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
315 mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
326 @subsubheading stable/2.12
328 If releasing stable/2.12, then:
333 apply doc patch: patches/rsync-lily.patch (or something like
337 change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
338 to "lilypond-web.info"
341 @subsubheading Updating a release (changing a in x.y.z-a)
343 Really tentative instructions, almost certainly can be done
349 change the VERSION back to release you want. push change.
350 (hopefully you'll have forgotten to update it when you made your
354 make sure that there aren't any lilypond files floating around in
355 target/ (like usr/bin/lilypond).
358 build the specific package(s) you want, i.e.
361 bin/gub mingw::lilypond-installer
362 make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
363 bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
368 build everything with the normal "make lilypond", then (maybe)
369 manually delete stuff you don't want to upload.
372 manually upload them. good luck figuring out the rsync
373 command(s). Hints are in test-lily/
377 run the normal lilypond-upload command, and (maybe) manually
378 delete stuff you didn't want to upload from the server.
383 @node Administrative policies
384 @section Administrative policies
386 Not really release-specific notes, but I don't see enough material
387 here to make it a separate chapter, and the release person will
388 probably be the one taking care of this anyway.
390 @subsubheading Language-specific mailing lists
392 A translator can ask for an official lilypond-xy mailing list once
393 they've finished all @qq{priority 1} translation items.
395 @subsubheading Performing yearly copyright update (@qq{grand-replace})
397 At the start of each year, copyright notices for all source files
398 should be refreshed by running the following command from the top of
405 Internally, this invokes the script @file{scripts/build/grand-replace.py},
406 which performs a regular expression substitution for old-year -> new-year
407 wherever it finds a valid copyright notice.
409 Note that snapshots of third party files such as @file{texinfo.tex} should
410 not be included in the automatic update; @file{grand-replace.py} ignores these
411 files if they are listed in the variable @code{copied_files}.