Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fewbar.com from 65.98.207.160 cause and error)
Content-Type: text/plain; charset=UTF-8
To: internals <internals@lists.php.net>
In-reply-to: <4F50EA41.1080706@php.net>
References: <CAEZPtU7qpMr9ZTX=+NDus05WA2RZ9A3rWNnHSr8WOBXjqbp4VQ@mail.gmail.com> <4F50EA41.1080706@php.net>
Date: Fri, 02 Mar 2012 09:39:31 -0800
Message-ID: <1330709339-sup-799@fewbar.com>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
From: clint@ubuntu.com (Clint Byrum)

Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
> > https://wiki.php.net/rfc/php53eol
> 
>   I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
>   and Stefan had an interesting idea: why not announce (now) that PHP 5.3
>   will go into EOL a year after PHP 5.5 comes out?
> 
>     * Now until PHP 5.5 comes out: bug and security fixes for PHP 5.3
>     * From the release of PHP 5.5: security fixes for PHP 5.3 for a year
> 
>   Ideally, PHP 5.5 would be out in a year from now, so it would come down
>   to one year of bug and security fixes and one year of security fixes
>   only. Makes sense to me.
> 

Just chiming in from the Ubuntu side of things. I think this is the most
predictable, and helpful plan for users and for distributors.

From the user standpoint, its quite useful to know where you stand
for upgrade path. This should make conservative users comfortable with
using 5.3 on existing projects until 5.5 enters RC phase, and then they
can start evaluating their options to move to 5.5 or 5.4, as they know
they'll have a whole year to evaluate 5.5. If you put a clock on 5.3,
and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4
only, and you may actually *miss* the opportunity to get people on the
latest release.

From a distribution standpoint, anything that lengthens the amount of time
that PHP as a project fully supports a release makes our burden smaller,
and gives our users a better chance at having stable software for the
entire life of our LTS releases. Selfish, I know, but just stating the
obvious fact.