Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26214
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.192 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=P2Cg6da+s9xM8yTmdPaNBy6NBUguejdlKVM8PsARmSJLd+InF911b1IezqCRFA/UVdpsB5KHWzjhVrsJ/heQbZm9sX7vEvWj7ehdmaQuWHzuFUmFwEbklKqyRW5b6J8ATv0BEe4bOccFsGDL39vuOqT2Rs9PvK2n3SDNb+Ywf1g=
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org>
Cc: Marcus Boerger <helly@php.net>
Content-Transfer-Encoding: 7bit
Date: Mon, 23 Oct 2006 20:33:05 -0400
To: php internals LIST <internals@lists.php.net>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Why 5.2 should not be delayed for E_DEPRECATED
From: ilia@prohost.org (Ilia Alshanetsky)

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