Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18805 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54781 invoked by uid 1010); 13 Sep 2005 00:33:31 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 54766 invoked from network); 13 Sep 2005 00:33:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Sep 2005 00:33:31 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:33525] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id E9/72-27924-A5E16234 for ; Mon, 12 Sep 2005 20:33:31 -0400 Received: (qmail 21287 invoked from network); 13 Sep 2005 00:33:24 -0000 Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1) by localhost with SMTP; 13 Sep 2005 00:33:24 -0000 Message-ID: <6.2.3.4.2.20050912173109.034612f0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 12 Sep 2005 17:33:22 -0700 To: pierre.php@gmail.com,Zeev Suraski Cc: internals@lists.php.net In-Reply-To: References: <5.1.0.14.2.20050912173631.07038640@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] 5.0.5, BC break, fatal error From: andi@zend.com (Andi Gutmans) Hey Pierre, Mini releases are not only for security fixes. We also do bug fixes, and sometimes even minor functionality (like a new function) which has very low risk of breaking anything. I don't think 5.0.5 is different from that. I do think we could probably be better at communicating these kind of breakages. Question is wether we should just try harder, or if you have some other concrete ideas which would be easy to implement and stick to? Andi At 07:50 AM 9/12/2005, Pierre Joye wrote: >On 9/12/05, Zeev Suraski wrote: > > > I don't think you're going to get a very good answer here. It boils down > > to what you already know - it's a bug which results in corruption, and > > that's the only way to fix it. The common decision was that it's more > > important to fix this bug than to maintain compatibility, and this even > > resulted in a new PHP 'family' (4.4). It's one of those cases where > > there's no good solution, only a choice of bad solutions. > >4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied >the patch to 5.1 not to 5.0.5. We did agree to apply it there and not >in bug fix releases (and not in security release). Or can you point me >to the common decision? ;) > >The bad solution is to do not communicate about that. Reading the >announce of 5.0.5, the only real problem was xml_rpc... If one has >asked to apply the fix to 5.0.5, I'm pretty sure nobody will agree to >add this fatal error. > >Regards, > >--Pierre > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php