| [ << Release work ] | [Top][Contents][Index][ ? ] | [ >> ] | ||
| [ < Release work ] | [ Up : Release work ] | [ Minor release checklist > ] | ||
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.xversion, 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.
- Any change to the input syntax. If a file compiled with a
previous
- 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.xis 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.
| [ << Release work ] | [Top][Contents][Index][ ? ] | [ >> ] | ||
| [ < Release work ] | [ Up : Release work ] | [ Minor release checklist > ] | ||