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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
