[ << 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.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.
- 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.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.
[ << Release work ] | [Top][Contents][Index][ ? ] | [ >> ] | ||
[ < Release work ] | [ Up : Release work ] | [ Minor release checklist > ] |