@c -*- coding: us-ascii; mode: texinfo; -*-
@node Release work
@chapter Release work

@menu
* Development phases::          
* Minor release checklist::     
* Major release checklist::     
* Making a release::
@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}.

email brief summary to info-lilypond



@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.

* 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

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



@node Making a release
@section Making a release

@subheading Technical notes

To build GUB:

@itemize

@item 
Run the following (from the gub/ dir):

@example
make -f lilypond.make update-versions
@end example

@item
Download
@uref{http://lilypond.org/download/binaries/test-output/lilypond-2.13.0-0.test-output.tar.bz2,lilypond-2.13.0-0.test-output.tar.bz2}

@item 
Copy / move / link it to uploads, but rename it to
@file{lilypond-2-13.test-output.tar.bz2}

@item
Run:

@example
make lilypond
@end example

@end itemize

To upload:

@itemize

@item remove the "t" from the rsync command in test-lily/rsync-lily-doc.py

@item run:

@example
python test-lily/upload.py --branch=master --url git://git.sv.gnu.org/lilypond.git --execute
@end example

@end itemize


@subheading Policy notes

@itemize

@item
Build with GUB, and check the regtests.

@item
Upload the tarballs and sh scripts.

@item
(if major)
Branch MASTER to stable/2.x.

@item
Make announcement.

@end itemize