Release scheduling, branching & NEWS for 5.4 View as Markdown

Hi!

I am noticing that the new way we're doing releases in 5.4 is not
completely clear to everybody, so I would like to reiterate some points.

1. 5.4 releases are done from release branch (PHP-5.4.X, e.g. current
   one is PHP-5.4.7). This branch is created 2 weeks before the release,
   usually on Tuesday, and is released as RC1. Usually, the same code is
   released two weeks later as official release. This is supposed to happen
   every month, unless something unexpected happens.

2. Once release branch is created, and until it is released, no code
   changes are accepted into the release branch, except for:

• critical security bugs (remote exploits, remote DoS, etc.)
• serious regressions from previous version
• grave bugs that make the release impossible

3. This means that every bug that is entered after the branch point is
   not getting into the branched release, unless it is a very critical bug
   and even then only if it is explicitly picked up by RMs. Which means the
   bug should be listed in the NEWS file as belonging to the next version
   (which at this point is 1.5 months away). I am trying to watch it and
   clean it up but please when you are committing the bugfixes pay
   attention to it, it makes the work of the RMs easier. The best and
   easiest way is just to enter your fix under the tompost version listed
   in the NEWS file.
   If you feel any particular bug is so severe that it must go into earlier
   version than it's supposed to go by default, please send a note to the
   list and/or to the RMs.

4. 5.3 and 5.4 are stable versions. This means by default new features
   should not be added there, but go into 5.5 (master), and no BC-breaking
   changes can be done in 5.3 or 5.4. However, we occasionally make
   exceptions for small features in 5.4. The proper way to do this is
   before merging the change to send a message to the list and to the RMs,
   notifying of the change (with pull URL) and asking if it's fine to do
   it. It is not because we doubt the quality of anybody's code or think
   the patch is somehow not good enough - it is to make everybody
   explicitly aware of the change and give chance to people to raise
   objections in the (unlikely) case there's some unnoticed problem with
   the change.

I would like to thank everybody that is contributing for their work and
I hope following these rules will allow us to maintain the quality of
the releases and avoid errors.

Thanks,

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227