]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/contributor/release-work.itexi
Merge branch 'master' into lilypond/translation
[lilypond.git] / Documentation / contributor / release-work.itexi
1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @node Release work
3 @chapter Release work
4
5 @menu
6 * Development phases::
7 * Minor release checklist::
8 * Major release checklist::
9 * Release extra notes::
10 * Administrative policies::
11 @end menu
12
13
14 @node Development phases
15 @section Development phases
16
17 There are 2.5 states of development for LilyPond.
18
19 @itemize
20
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:
24
25 @itemize
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
28 version.
29
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.
33
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
38 version.
39
40 @end itemize
41
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.
45
46
47 @item @strong{Release prep phase}:
48 TODO: I don't like that name.
49
50 A new git branch @code{stable/2.x} is created, and a major release
51 is made in two weeks.
52
53 @itemize
54
55 @item @code{stable/2.x branch}:
56 Only translation updates and important bugfixes are allows.
57
58 @item @code{master}:
59 Normal @qq{stable phase} development occurs.
60
61 @end itemize
62
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.
65
66 @end itemize
67
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.
73
74
75
76 @node Minor release checklist
77 @section Minor release checklist
78
79 A @qq{minor release} means an update of @code{y} in @code{2.x.y}.
80
81 @subheading Pre-release
82
83 @enumerate
84
85 @item
86 Switch to the release branch, get changes, prep release
87 announcement:
88
89 @example
90 git checkout release/unstable
91 git merge origin
92 vi Documentation/web/news-front.itexi Documentation/web/news.itexi
93 @end example
94
95 @item
96 Commit, push, switch back to master:
97
98 @example
99 git commit -m "Release: update news." Documentation/web/
100 git push origin
101 git checkout master
102 git merge release/unstable
103 @end example
104
105 @item (optional) Check that lilypond builds from scratch in an
106 out-of-tree build.
107
108 @item
109 If you do not have the previous release test-output tarball, download
110 it and put it in @code{regtests/}
111
112 @item Build release on GUB by running:
113
114 @example
115 make LILYPOND_BRANCH=release/unstable lilypond
116 @end example
117
118 @noindent
119 or something like:
120
121 @example
122 make LILYPOND_BRANCH=stable/2.12 lilypond
123 @end example
124
125 @item Check the regtest comparison in @file{uploads/webtest/} for
126 any unintentional breakage.
127
128 Note that this test uses the bounding boxes inside lilypond.
129 Errors in ghostscript don't generate differences inside lilypond,
130 so they are not registered in the regtest comparison.
131
132 @item If any work was done on GUB since the last release, upload
133 binaries to a temporary location, ask for feedback, and wait a day
134 or two in case there's any major problems.
135
136 @end enumerate
137
138
139 @subheading Actual release
140
141 @enumerate
142
143 @item If you're not right user on the webserver, remove the "t"
144 from the rsync command in @file{test-lily/rsync-lily-doc.py} and
145 @file{test-lily/rsync-test.py}
146
147 @code{graham} owns v2.13; @code{han-wen} owns v2.12.
148
149 @item Upload GUB by running:
150
151 @example
152 make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
153 @end example
154
155 @noindent
156 or something like:
157
158 @example
159 make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git
160 @end example
161
162 @end enumerate
163
164
165 @subheading Post release
166
167 @enumerate
168
169 @item Switch back to master and get the updated news:
170
171 @example
172 git checkout master
173 git merge release/unstable
174 @end example
175
176 @item Update @file{VERSION} in lilypond git:
177
178 @example
179 VERSION = what you just did +0.0.1
180 DEVEL_VERSION = what you just did (i.e. is now online)
181 STABLE_VERSION = what's online
182 @end example
183
184 @item Push changes.
185
186 @item (for now) do a @code{make doc} and manually upload:
187
188 @example
189 ### upload-lily-web-media.sh
190 #!/bin/sh
191 BUILD_DIR=$HOME/src/build-lilypond
192
193 PICS=$BUILD_DIR/Documentation/pictures/out-www/
194 EXAMPLES=$BUILD_DIR/Documentation/web/ly-examples/out-www/
195
196 cd $BUILD_DIR
197 rsync -a $PICS graham@@lilypond.org:media/pictures
198 rsync -a $EXAMPLES graham@@lilypond.org:media/ly-examples
199 @end example
200
201 @item Wait a few hours for the website to update.
202
203 @item Email release notice to @code{info-lilypond}
204
205 @end enumerate
206
207
208
209 @node Major release checklist
210 @section Major release checklist
211
212 A @qq{major release} means an update of @code{x} in @code{2.x.0}.
213
214 - happens when we have 0 Critical issues for two weeks (14 days).
215
216
217 Before release:
218
219 * write release notes. note: stringent size requirements for
220  various websites, so be brief.
221
222 * write preface section for manual.
223
224 * submit pots for translation : send url of tarball to
225 translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot
226
227 * Check reg test
228
229 * Check all 2ly scripts.
230
231 * Run convert-ly on all files, bump parser minimum version.
232
233 * update links to distros providing lilypond packages?  link in
234 Documentation/web/download.itexi .  This has nothing to do with
235 the release, but I'm dumping this here so I'll find it when I
236 reorganize this list later.  -gp
237
238 * Make FTP directories on lilypond.org
239
240 * website:
241   - Make new table in download.html
242
243   - add to documentation list
244
245   - revise examples tour.html/howto.html
246
247   - add to front-page quick links
248
249   - change all links to the stable documentation
250
251   - doc auto redirects  to v2.LATEST-STABLE
252
253   - add these two lines to http://www.lilypond.org/robots.txt:
254
255 @example
256 Disallow: /doc/v2.PREVIOUS-STABLE/
257 Disallow: /doc/v2.CURRENT-DEVELOPMENT/
258 @end example
259
260 - check for emergencies the docs:
261
262 @example
263 grep FIXME --exclude "misc/*" --exclude "*GNUmakefile" \
264   --exclude "snippets/*" ????*/*
265 @end example
266
267 - check for altered regtests, and document as necessary.  (update
268   tags as appropriate)
269
270 @example
271 git diff -u -r release/2.12.0-1 -r release/2.13.13-1 input/regression/
272 @end example
273
274
275 News:
276
277         comp.music.research
278         comp.os.linux.announce
279
280         comp.text.tex
281         rec.music.compose
282
283 Mail:
284
285         info-lilypond@@gnu.org
286
287 linux-audio-announce@@lists.linuxaudio.org
288 linux-audio-user@@lists.linuxaudio.org
289 linux-audio-dev@@lists.linuxaudio.org
290
291         tex-music@@icking-music-archive.org
292
293    --- non-existant?
294         abcusers@@blackmill.net
295
296         rosegarden-user@@lists.sourceforge.net
297         info-gnu@@gnu.org
298         noteedit-user@@berlios.de
299
300         gmane.comp.audio.fomus.devel
301         gmane.linux.audio.users
302         gmane.linux.audio.announce
303         gmane.comp.audio.rosegarden.devel
304
305 Web:
306
307         lilypond.org
308         freshmeat.net
309         linuxfr.com
310         http://www.apple.com/downloads
311         harmony-central.com (news@@harmony-central.com)
312         versiontracker.com [auto]
313         hitsquad.com [auto]
314         http://www.svgx.org
315         https://savannah.gnu.org/news/submit.php?group_id=1673  @c => planet.gnu.org
316
317
318 @node Release extra notes
319 @section Release extra notes
320
321 @subsubheading Regenerating regression tests
322
323 Regenerating regtests (if the lilypond-book naming has changed):
324
325 @itemize
326
327 @item
328 git checkout release/lilypond-X.Y.Z-A
329
330 @item
331 take lilypond-book and any related makefile updates from the
332 latest git.
333
334 @item
335 - configure; make; make test
336
337 @item
338 tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/
339
340 @item
341 mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/
342
343 @item
344 cd ../gub/regtests/
345
346 @item
347 make lilypond
348
349 @end itemize
350
351
352 @subsubheading stable/2.12
353
354 If releasing stable/2.12, then:
355
356 @itemize
357
358 @item
359 apply doc patch: patches/rsync-lily.patch  (or something like
360 that)
361
362 @item
363 change infodir in gub/specs/lilypond-doc.py from "lilypond.info"
364 to "lilypond-web.info"
365 @end itemize
366
367 @subsubheading Updating a release (changing a in x.y.z-a)
368
369 Really tentative instructions, almost certainly can be done
370 better.
371
372 @enumerate
373
374 @item
375 change the VERSION back to release you want.  push change.
376 (hopefully you'll have forgotten to update it when you made your
377 last release)
378
379 @item
380 make sure that there aren't any lilypond files floating around in
381 target/  (like usr/bin/lilypond).
382
383 @item
384 build the specific package(s) you want, i.e.
385
386 @example
387 bin/gub mingw::lilypond-installer
388 make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc
389 bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12'
390 @end example
391
392 or
393
394 build everything with the normal "make lilypond", then (maybe)
395 manually delete stuff you don't want to upload.
396
397 @item
398 manually upload them.  good luck figuring out the rsync
399 command(s).  Hints are in test-lily/
400
401 or
402
403 run the normal lilypond-upload command, and (maybe) manually
404 delete stuff you didn't want to upload from the server.
405
406 @end enumerate
407
408
409 @node Administrative policies
410 @section Administrative policies
411
412 Not really release-specific notes, but I don't see enough material
413 here to make it a separate chapter, and the release person will
414 probably be the one taking care of this anyway.
415
416 @subsubheading Language-specific mailing lists
417
418 A translator can ask for an official lilypond-xy mailing list once
419 they've finished all @qq{priority 1} translation items.
420
421 @subsubheading Performing yearly copyright update (@qq{grand-replace})
422
423 At the start of each year, copyright notices for all source files
424 should be refreshed by running the following command from the top of
425 the source tree:
426
427 @example
428 make grand-replace
429 @end example
430
431 Internally, this invokes the script @file{scripts/build/grand-replace.py},
432 which performs a regular expression substitution for old-year -> new-year
433 wherever it finds a valid copyright notice.
434
435 Note that snapshots of third party files such as @file{texinfo.tex} should
436 not be included in the automatic update; @file{grand-replace.py} ignores these
437 files if they are listed in the variable @code{copied_files}.