Newsgroups: php.internals,php.qa Path: news.php.net Xref: news.php.net php.internals:36730 php.qa:64137 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21291 invoked from network); 31 Mar 2008 21:18:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Mar 2008 21:18:47 -0000 Authentication-Results: pb1.pair.com header.from=johannes@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.163 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 83.243.58.163 mail4.netbeat.de Received: from [83.243.58.163] ([83.243.58.163:35993] helo=mail4.netbeat.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A6/A0-17962-63551F74 for ; Mon, 31 Mar 2008 16:18:47 -0500 Received: (qmail 32158 invoked by uid 507); 31 Mar 2008 21:18:40 -0000 Received: from unknown (HELO ?192.168.1.102?) (postmaster%schlueters.de@82.135.0.128) by mail4.netbeat.de with ESMTPA; 31 Mar 2008 21:18:40 -0000 To: Marcus Boerger Cc: Derick Rethans , Marco Kaiser , 'PHP Developers Mailing List' , php-qa@lists.php.net, Ilia Alshanetsky In-Reply-To: <826883759.20080331171437@marcus-boerger.de> References: <1124764115.20080327105033@marcus-boerger.de> <47eb9d50.02e2660a.759d.2e19@mx.google.com> <826883759.20080331171437@marcus-boerger.de> Content-Type: text/plain Date: Mon, 31 Mar 2008 23:18:34 +0200 Message-ID: <1206998314.2941.6.camel@goldfinger> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit Subject: Re: [PHP-QA] BC break with php 5.2.6 From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=) Marcus, On Mon, 2008-03-31 at 17:14 +0200, Marcus Boerger wrote: > Hello Derick, > > it is a BUG FIX. Not fixing it means more people will turn it into a > feature and we will never be able to remove it. Becuase next time you > will say we cannot remove it in a minor version as by then you accidentally > rely on it yourself. > > We made a mistake! Lets stand up and admit we did. Probably I was involved > in making that mistake, so sorry. Done. I have to agree with Derick here we shouldn't add a fatal error within a bug fix release at such a place. People (hosters...) tend to update versions without checking all incompatibilities - since you don't expect them and they want to get security issues fixed. Yes, the previous behavior was wrong! Yes we shouldn't encourage people do do that. I'd propose making it an Warning or something in 5.2 and fixing it in 5.3. johannes