Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <7.0.1.0.2.20061024085428.053f9cf8@zend.com>
Date: Tue, 24 Oct 2006 08:55:38 +0200
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: php internals LIST <internals@lists.php.net>,
 Marcus Boerger <helly@php.net>
In-Reply-To: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org>
References: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
From: zeev@zend.com (Zeev Suraski)

Ilia,

I think Wez's suggestion is the most practical one.  Let's make sure 
we haven't introduced any fatal errors into 5.2 (and demote them to 
E_STRICT for now), and handle the rest of the suggestions afterwards.

Zeev

At 02:33 24/10/2006, Ilia Alshanetsky wrote:
>I've been reading people's replies to Marcus' RFC in regard to
>E_DEPRECATED and it seems that some people have expressed the want to
>delay 5.2 until mucking around with error handling is done one way or
>another. My simple answer to this is no.
>
>The long answer is as follows.
>
>PHP 5.2.0 is not the last 5.X release, there will be more patch level
>versions and at the very least at least one more major version, so we
>should not be trying to stuff every single feature under the sun
>into  it as if it was the end of the 5 series. Furthermore, it makes
>little sense to make drastic error handling changes this late in the
>game, rushing the decision process and possibly excluding developers
>who do not read the list every day or are currently away. It should
>go through an extensive peer review and comment process, be tested,
>tried with real applications to see what breaks and so on, this is
>not a trivial change. Another words it is too major of a change to do
>at the last minute, rushing it will only lead to problems we'd end up
>cleaning up for many more releases to come. We also need to remember
>that 5.2 is already way behind schedule, which is important because
>it contains a fair number of security fixes, without which a good
>number of users are vulnerable to a variety of exploits. Delaying the
>release means not deploying those fixes and in my opinion is a
>disservice to all users of PHP.
>
>In my opinion we need to make a release, continue considering
>Marcus' RFC, develop a patch and push it to our real development tree
>PHP 6.0. If it proves to be solid and does not break (m)any
>applications it would be the first candidate to back-port to 5 series
>once 5.3 is under consideration.
>
>
>Ilia Alshanetsky
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php