Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76564
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <53EE5087.9040305@sugarcrm.com>
Date: Fri, 15 Aug 2014 11:25:11 -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: Ferenc Kovacs <tyra3l@gmail.com>, Jan Ehrhardt <phpdev@ehrhardt.nl>
CC: PHP Internals <internals@lists.php.net>
References: <rnaqu9pp4im9uro4j52a5ocmtn4vkccgm2@4ax.com> <CAH-PCH7WoDsJAZKevRJ2vGauL-jL3KWQTwYm8iQJY-bG0w80aw@mail.gmail.com>
In-Reply-To: <CAH-PCH7WoDsJAZKevRJ2vGauL-jL3KWQTwYm8iQJY-bG0w80aw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Status of PHP 5.4
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> the release process rfc (https://wiki.php.net/rfc/releaseprocess) governs
> the releases since 5.4: 2+1 year of support after the initial X.Y.0 release.
> as pointed out, 5.4 is already past the 2 years of bugfix support, so we
> should announce it that it is on security fixes only.

5.4.32 is already in RC and will be released next week. 5.4.33-dev is
already containing some non-security fixes. So we could just arbitrarily
announce that starting noon today we stop accepting non-security
bugfixes into 5.4, or we could choose a less arbitrary cutoff - such as
release of 5.6 or 5.4.33. I would prefer the less arbitrary route, I
don't see much harm in having the bugfixes last a little longer, but
having more natural version succession - i.e. saying we always have 2
stable branches and one in security fixes.

> process rfc and announce the extended support and EOL dates based on the
> original release date, or update the releaseprocess RFC to state that we
> move into extended support/EOL when the the new version in that year is
> released.

I think it would be more natural and accommodating for the realities of
the release process. The thing is we will have delays, we will have bad
RCs, we will have people going on vacations or being too busy, and
having a scheme that can accept this while still preserving the general
structure seems better to me than literal day-counting. If this means
5.4 has extra 1/2 year of bugfixes - I don't see big harm done by that.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/