GNU LilyPond Contributor's Guide: 8.1 Development phases

## 8.1 Development phases

There are 2.5 states of development for LilyPond.

- Stable phase: Starting from the release of a new major version `2.x.0`, the following patches MAY NOT be merged with master:
  - Any change to the input syntax. If a file compiled with a previous `2.x` version, then it must compile in the new version.
  - New features with new syntax may be committed, although once committed that syntax cannot change during the remainder of the stable phase.
  - 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 `2.x`, then he must be able to compile the new version.
- Development phase: Any commits are fine. Readers may be familiar with the term “merge window” from following Linux kernel news.
- Release prep phase: FIXME: I don’t like that name.

  A new git branch `stable/2.x` is created, and a major release is made in two weeks.

  - `stable/2.x branch`: Only translation updates and important bugfixes are allows.
  - `master`: Normal “stable phase” development occurs.

  If we discover the need to change the syntax or build system, we will apply it and re-start the release prep phase.

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.

#### Contributor’s Guide