Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26229
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.20061024163800.0e00e218@zend.com>
Date: Tue, 24 Oct 2006 16:38:53 +0200
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: php internals LIST <internals@lists.php.net>,
 Marcus Boerger <helly@php.net>
In-Reply-To: <F2137416-B788-4C8F-80C5-FEC0AFCD31D2@prohost.org>
References: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org>
 <7.0.1.0.2.20061024085428.053f9cf8@zend.com>
 <F2137416-B788-4C8F-80C5-FEC0AFCD31D2@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)

Well I'm definitely not referring to those, only the new strict OO 
fatals as per Marcus's original message...

Zeev

At 16:32 24/10/2006, Ilia Alshanetsky wrote:
>Zeev,
>
>There are probably 5-6 new fatal errors in the engine since 5.1, some
>of which cannot be delegated to lower error reporting modes as they
>may cause engine instability or similar problems. Rasmus was going to
>make a list of all the newly added engine error changes, hopefully
>he'll have that list soon.
>
>
>On 24-Oct-06, at 2:55 AM, Zeev Suraski wrote:
>
>>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
>>
>>--
>>PHP Internals - PHP Runtime Development Mailing List
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>Ilia Alshanetsky
>
>
>