Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76673
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <53F29345.40607@sugarcrm.com>
Date: Mon, 18 Aug 2014 16:59:01 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: 5.4 security only
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:

- 5.4.32 is released as planned this week, nothing changes there.

- 5.4 branch that is to be 5.4.33 will be the last release that has any
non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
out too, so that would play nice with the "two stable branches, one
security branch" theme. Starting from that release forward, 5.4 would be
purely security fixes only branch.

- EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
5.4 branch unless they are very important ones (and that is only because
people may, in theory, have pending patches and we didn't give advance
notice). Importance would have to be determined somewhat arbitrarily,
but basically if it works without it, then it's not in, if there's
serious doubt if it should be in, it's not in, etc. Security issues, of
course, still allowed in.

This means if somebody has some pending non-security fixes that have to
be in 5.4, the following two weeks are the last call, provided that the
fixes really must be in 5.4.

Any objections/suggested modifications to this plan?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/