Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26227 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12171 invoked by uid 1010); 24 Oct 2006 14:32:36 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 12156 invoked from network); 24 Oct 2006 14:32:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2006 14:32:36 -0000 Authentication-Results: pb1.pair.com header.from=iliaal@gmail.com; sender-id=pass; domainkeys=good Authentication-Results: pb1.pair.com smtp.mail=iliaal@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.228 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: iliaal@gmail.com X-Host-Fingerprint: 66.249.82.228 wx-out-0506.google.com Linux 2.4/2.6 Received: from [66.249.82.228] ([66.249.82.228:23844] helo=wx-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/60-30135-1042E354 for ; Tue, 24 Oct 2006 10:32:34 -0400 Received: by wx-out-0506.google.com with SMTP id s18so2472298wxc for ; Tue, 24 Oct 2006 07:32:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=L3ovevDScRo+9t4zTpwy0pRJjAOi2BDkQVZG54b66lLwV7vJT3e+Paa1FDTGy0Fvj1gKnkhcAi8ioXUDnes6kjo0B3Nfugz2xXuqR/+dWCAHEiDBQBg9Ilw6hJkZhEp+U1zLObLsMfCLSsJ94jBPjwwhtqRFX+4YyGkxvWDAK7Y= Received: by 10.70.109.12 with SMTP id h12mr3081784wxc; Tue, 24 Oct 2006 07:32:30 -0700 (PDT) Received: from ?192.168.1.6? ( [74.108.69.82]) by mx.google.com with ESMTP id q18sm768232qbq.2006.10.24.07.32.29; Tue, 24 Oct 2006 07:32:29 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20061024085428.053f9cf8@zend.com> References: <7.0.1.0.2.20061024085428.053f9cf8@zend.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: Cc: php internals LIST , Marcus Boerger Content-Transfer-Encoding: 7bit Date: Tue, 24 Oct 2006 10:32:21 -0400 To: Zeev Suraski X-Mailer: Apple Mail (2.752.3) Sender: Ilia Alshanetsky Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED From: ilia@prohost.org (Ilia Alshanetsky) 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