@c -*- coding: utf-8; mode: texinfo; -*- @node Release work @chapter Release work @menu * Development phases:: * Minor release checklist:: * Major release checklist:: * Release extra notes:: @end menu @node Development phases @section Development phases There are 2.5 states of development for LilyPond. @itemize @item @strong{Stable phase}: Starting from the release of a new major version @code{2.x.0}, the following patches @strong{MAY NOT} be merged with master: @itemize @item Any change to the input syntax. If a file compiled with a previous @code{2.x} version, then it must compile in the new version. @item New features with new syntax @emph{may be committed}, although once committed that syntax cannot change during the remainder of the stable phase. @item Any change to the build dependencies (including programming libraries, documentation process programs, or python modules used in the buildscripts). If a contributor could compile a previous lilypond @code{2.x}, then he must be able to compile the new version. @end itemize @item @strong{Development phase}: Any commits are fine. Readers may be familiar with the term @qq{merge window} from following Linux kernel news. @item @strong{Release prep phase}: FIXME: I don't like that name. A new git branch @code{stable/2.x} is created, and a major release is made in two weeks. @itemize @item @code{stable/2.x branch}: Only translation updates and important bugfixes are allows. @item @code{master}: Normal @qq{stable phase} development occurs. @end itemize If we discover the need to change the syntax or build system, we will apply it and re-start the release prep phase. @end itemize This marks a radical change from previous practice in LilyPond. However, this setup is not intended to slow development -- as a rule of thumb, the next development phase will start within a month of somebody wanting to commit something which is not permitted during the stable phase. @node Minor release checklist @section Minor release checklist A @qq{minor release} means an update of @code{y} in @code{2.x.y}. @subheading Pre-release @enumerate @item Add a news item to @file{Documentation/web/news-front.itexi} @item Check that lilypond builds from scratch in an out-of-tree build. @item If you do not have the previous release test-output tarball, download it and put it in @code{regtests/} @item Build release on GUB by running: @example make lilypond @end example @noindent or something like: @example make LILYPOND_BRANCH=stable/2.12 lilypond @end example @item Check the regtest comparison in @file{uploads/webtest/} for any unintentional breakage. @item Check if the mingw build contains lilypad.exe; when you find that it doesn't, rebuild @code{mingw::lilypond-installer}. Repeat as necessary. @uref{http://code.google.com/p/lilypond/issues/detail?id=901} @item If any work was done on GUB since the last release, upload binaries to a temporary location, ask for feedback, and wait a day or two in case there's any major problems. @end enumerate @subheading Post-release @enumerate @item If you're not right user on the webserver, remove the "t" from the rsync command in @file{test-lily/rsync-lily-doc.py} and @file{test-lily/rsync-test.py} @code{graham} owns v2.13; @code{han-wen} owns v2.12. @item Upload GUB by running: @example make lilypond-upload LILYPOND_BRANCH=master LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git @end example @noindent or something like: @example make lilypond-upload LILYPOND_BRANCH=stable/2.12 LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git @end example @item Update @file{VERSION} in lilypond git. @item Wait a few hours for the website to update. @item Email release notice to @code{info-lilypond} @end enumerate @node Major release checklist @section Major release checklist A @qq{major release} means an update of @code{x} in @code{2.x.0}. Before release: * write release notes. note: stringent size requirements for various websites, so be brief. * write preface section for manual. * submit pots for translation : send url of tarball to translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot * Check reg test * Check all 2ly scripts. * Run convert-ly on all files, bump parser minimum version. * update links to distros providing lilypond packages? link in Documentation/web/download.itexi . This has nothing to do with the release, but I'm dumping this here so I'll find it when I reorganize this list later. -gp * Make FTP directories on lilypond.org * website: - Make new table in download.html - add to documentation list - revise examples tour.html/howto.html - add to front-page quick links - change all links to the stable documentation - doc auto redirects to v2.LATEST-STABLE - add these two lines to http://www.lilypond.org/robots.txt: @example Disallow: /doc/v2.PREVIOUS-STABLE/ Disallow: /doc/v2.CURRENT-DEVELOPMENT/ @end example News: comp.music.research comp.os.linux.announce comp.text.tex rec.music.compose Mail: info-lilypond@@gnu.org linux-audio-announce@@lists.linuxaudio.org linux-audio-user@@lists.linuxaudio.org linux-audio-dev@@lists.linuxaudio.org tex-music@@icking-music-archive.org --- non-existant? abcusers@@blackmill.net rosegarden-user@@lists.sourceforge.net info-gnu@@gnu.org noteedit-user@@berlios.de gmane.comp.audio.fomus.devel gmane.linux.audio.users gmane.linux.audio.announce gmane.comp.audio.rosegarden.devel Web: lilypond.org freshmeat.net linuxfr.com http://www.apple.com/downloads harmony-central.com (news@@harmony-central.com) versiontracker.com [auto] hitsquad.com [auto] http://www.svgx.org https://savannah.gnu.org/news/submit.php?group_id=1673 @c => planet.gnu.org @node Release extra notes @section Release extra notes If releasing stable/2.12, then: - apply doc patch: patches/rsync-lily.patch (or something like that) - change infodir in gub/specs/lilypond-doc.py from "lilypond.info" to "lilypond-web.info" GENERAL STUFF TO BE MOVED ELSEWHERE Regenerating regtests (if the lilypond-book naming has changed): - git checkout release/lilypond-X.Y.Z-A - take lilypond-book and any related makefile updates from the latest git. - configure; make; make test - tar -cjf lilypond-X.Y.Z-A.test-output.tar.bz2 input/regression/out-test/ - mv lilypond-X.Y.Z-A.test-output.tar.bz2 ../gub/regtests/ - cd ../gub/regtests/ - make lilypond New contributor / mentor idea: - tell them to spend 10 minutes on a problem, then give up and ask for help from their mentor - the mentor should tell them if a "make clean; make" (or the same for docs) is required Latest website: - generated hourly on lilypond.org. Only split-HTML; big-html and pdf are not generated hourly (wait for the next devel release) VERSION-SPECIFIC MACROS - made with scripts/build/create-version-itexi.py - used extensively in the WEBSITE_ONLY_BUILD version of the website (made with website.make, and used on lilypond.org) - not (?) used in the main docs? - FIXME: the numbers in VERSION: MINOR should be 1 more than the last release, VERSION_DEVEL should be the last *online* release. LANGUAGE LISTS - a translator can ask for an official lilypond-xy mailing list once they've finished all "priority 1" translation items. UPDATING A RELEASE ( x.y.z-a, where a>1 ) really tentative instructions, almost certainly can be done better 1. change the VERSION back to release you want. push change. (hopefully you'll have forgotten to update it when you made your last release) 2. make sure that there aren't any lilypond files floating around in target/ (like usr/bin/lilypond). 3. build the specific package(s) you want, i.e. bin/gub mingw::lilypond-installer make LILYPOND_BRANCH=stable/2.12 -f lilypond.make doc bin/gub --platform=darwin-x86 'git://git.sv.gnu.org/lilypond-doc.git?branch=stable/2.12' 4. manually upload them. good luck figuring out the rsync command(s). Hints are in test-lily/ MAKING A RELEASE -- NEW INFO (wow, I really need to stop being so messy here. Will clean it up after 2.13.11; I need a chance to test these instructions) 1. switch to the release branch: git checkout release/unstable 1b. get latest changes git merge origin 2. make a release announcement by editing: Documentation/web/news-front.itexi (and maybe moving the oldest news item to news-old.itexi) 3. upload: git push release/unstable 4. make GUB as "normal" make LILYPOND_BRANCH=release/unstable -f lilypond.make doc (if this works, make it the default for GUB) 5. upload git, etc. 6. update VERSION, commit, push. VERSION = what you just did +0.0.1 DEVEL_VERSION = what you just did (i.e. is now online) STABLE_VERSION = what's online 7. switch back to master and merge the changes git merge release/unstable (FIXME: only if the release announcement+version are the only changes; if you hacked more stuff, then try cherry-picking) 8. (for now) manually upload Documentation/pictures/out-www/ Documentation/web/ly-examples/out-www/ to $HOME/media/pictures .../ly-examples on lilypond.org