Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26231 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29164 invoked by uid 1010); 24 Oct 2006 15:11:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 29149 invoked from network); 24 Oct 2006 15:11:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2006 15:11:03 -0000 Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 212.25.124.162 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from [212.25.124.162] ([212.25.124.162:40090] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 61/92-30135-50D2E354 for ; Tue, 24 Oct 2006 11:11:03 -0400 Received: (qmail 7194 invoked from network); 24 Oct 2006 15:09:35 -0000 Received: from localhost (HELO zeev-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 24 Oct 2006 15:09:35 -0000 Message-ID: <7.0.1.0.2.20061024170856.0583dd20@zend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 24 Oct 2006 17:10:46 +0200 To: "Hannes Magnusson" Cc: "Ilia Alshanetsky" , "php internals LIST" , "Marcus Boerger" In-Reply-To: <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.co m> References: <7.0.1.0.2.20061024085428.053f9cf8@zend.com> <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.com> 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) I think that a lot of those are legit - we only need to 'demote' the language-level warnings/errors that attempt to enforce strict OO standards. Warnings/errors that warn about unacceptable input are legitimate and should stay. Zeev At 16:57 24/10/2006, Hannes Magnusson wrote: >On 10/24/06, 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. > >Attached is a list (php examples) over all the backwards incompatible >error throwing I could find... >-Hannes > > > >> >> >>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 >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php >> > > >Content-Type: text/plain; name="backwards.incompatible.error.throwing.txt" >Content-Disposition: attachment; >filename="backwards.incompatible.error.throwing.txt" >X-Attachment-Id: f_etof8h3u