1 @c -*- coding: us-ascii; 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.5 states of development for LilyPond.
20 @item @strong{Stable phase}:
21 Starting from the release of a new major version @code{2.x.0}, the
22 following patches @strong{MAY NOT} be merged with master:
25 @item Any change to the input syntax. If a file compiled with a
26 previous @code{2.x} version, then it must compile in the new
29 @item New features with new syntax @emph{may be committed},
30 although once committed that syntax cannot change during the
31 remainder of the stable phase.
33 @item Any change to the build dependencies (including programming
34 libraries, documentation process programs, or python modules used
35 in the buildscripts). If a contributor could compile a previous
36 lilypond @code{2.x}, then he must be able to compile the new
41 @item @strong{Development phase}:
42 Any commits are fine. Readers may be familiar with the term
43 @qq{merge window} from following Linux kernel news.
46 @item @strong{Release prep phase}:
47 FIXME: I don't like that name.
49 A new git branch @code{stable/2.x} is created, and a major release
54 @item @code{stable/2.x branch}:
55 Only translation updates and important bugfixes are allows.
58 Normal @qq{stable phase} development occurs.
62 If we discover the need to change the syntax or build system, we
63 will apply it and re-start the release prep phase.
67 This marks a radical change from previous practice in LilyPond.
68 However, this setup is not intended to slow development -- as a
69 rule of thumb, the next development phase will start within a
70 month of somebody wanting to commit something which is not
71 permitted during the stable phase.
75 @node Minor release checklist
76 @section Minor release checklist
78 A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
80 @subheading Pre-release
84 @item Add a news item to @file{Documentation/web/news-front.itexi}
86 @item Check that lilypond builds from scratch in an out-of-tree
90 If you do not have the previous release test-output tarball, download
91 it and put it in @code{regtests/}
93 @item Build release on GUB by running:
103 make LILYPOND_BRANCH=stable/2.12 lilypond
107 @item Check the regtest comparison in @file{uploads/webtest/} for
108 any unintentional breakage.
110 @item Check if the mingw build contains lilypad.exe; when you find
111 that it doesn't, rebuild @code{mingw::lilypond-installer}. Repeat
114 @uref{http://code.google.com/p/lilypond/issues/detail?id=901}
116 @item If any work was done on GUB since the last release, upload
117 binaries to a temporary location, ask for feedback, and wait a day
118 or two in case there's any major problems.
123 @subheading Post-release
127 @item If you're not right user on the webserver, remove the "t"
128 from the rsync command in @file{test-lily/rsync-lily-doc.py} and
129 @file{test-lily/rsync-test.py}
131 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
133 @item Upload GUB by running:
136 make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
143 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
147 @item Update @file{VERSION} in lilypond git.
149 @item Wait a few hours for the website to update.
151 @item Email release notice to @code{info-lilypond}
156 @node Major release checklist
157 @section Major release checklist
159 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
163 * write release notes. note: stringent size requirements for
164 various websites, so be brief.
166 * write preface section for manual.
168 * submit pots for translation : send url of tarball to
169 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
173 * Check all 2ly scripts.
175 * Run convert-ly on all files, bump parser minimum version.
177 * update links to distros providing lilypond packages? link in
178 Documentation/web/download.itexi . This has nothing to do with
179 the release, but I'm dumping this here so I'll find it when I
180 reorganize this list later. -gp
182 * Make FTP directories on lilypond.org
185 - Make new table in download.html
187 - add to documentation list
189 - revise examples tour.html/howto.html
191 - add to front-page quick links
193 - change all links to the stable documentation
195 - doc auto redirects to v2.LATEST-STABLE
197 - add these two lines to http://www.lilypond.org/robots.txt:
200 Disallow: /doc/v2.PREVIOUS-STABLE/
201 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
207 comp.os.linux.announce
214 info-lilypond@@gnu.org
216 linux-audio-announce@@lists.linuxaudio.org
217 linux-audio-user@@lists.linuxaudio.org
218 linux-audio-dev@@lists.linuxaudio.org
220 tex-music@@icking-music-archive.org
223 abcusers@@blackmill.net
225 rosegarden-user@@lists.sourceforge.net
227 noteedit-user@@berlios.de
229 gmane.comp.audio.fomus.devel
230 gmane.linux.audio.users
231 gmane.linux.audio.announce
232 gmane.comp.audio.rosegarden.devel
239 http://www.apple.com/downloads
240 harmony-central.com (news@@harmony-central.com)
241 versiontracker.com [auto]
244 https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org
247 @node Release extra notes
248 @section Release extra notes
250 If releasing stable/2.12, then:
252 - apply doc patch: patches/rsync-lily.patch (or something like
255 - change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
256 to "lilypond-web.info"
259 GENERAL STUFF TO BE MOVED ELSEWHERE
261 Regenerating regtests (if the lilypond-book naming has changed):
263 - git checkout release/lilypond-X.Y.Z-A
265 - take lilypond-book and any related makefile updates from the
268 - configure; make; make test
270 - tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2
271 input/regression/out-test/
273 - mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
275 - cd ../gub/regtests/
280 New contributor / mentor idea:
282 - tell them to spend 10 minutes on a problem, then give up and ask
283 for help from their mentor
285 - the mentor should tell them if a "make clean; make" (or the same
286 for docs) is required
291 - generated hourly on lilypond.org. Only split-HTML; big-html and
292 pdf are not generated hourly (wait for the next devel release)
295 VERSION-SPECIFIC MACROS
297 - made with scripts/build/create-version-itexi.py
299 - used extensively in the WEBSITE_ONLY_BUILD version of the
300 website (made with website.make, and used on lilypond.org)
302 - not (?) used in the main docs?
304 - FIXME: the numbers in VERSION: MINOR should be 1 more than the
305 last release, VERSION_DEVEL should be the last *online* release.
310 - a translator can ask for an official lilypond-xy mailing list
311 once they've finished all "priority 1" translation items.