@c -*- coding: us-ascii; 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 idea: - tell them to spend 10 minutes on a problem, then give up and ask for help 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.