Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17249 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61079 invoked by uid 1010); 12 Jul 2005 21:32:51 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 61064 invoked from network); 12 Jul 2005 21:32:51 -0000 Received: from unknown (HELO ntlworld.com) (127.0.0.1) by localhost with SMTP; 12 Jul 2005 21:32:51 -0000 X-Host-Fingerprint: 82.1.27.86 spc2-hava1-4-0-cust86.cosh.broadband.ntl.com Received: from ([82.1.27.86:22390] helo=localhost.localdomain) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id C4/D9-23681-30734D24 for ; Tue, 12 Jul 2005 17:32:51 -0400 Message-ID: To: internals@lists.php.net Date: Tue, 12 Jul 2005 22:33:14 +0100 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050712105234.5dhkvvd6ghcsw8sg@marina.horde.org> <20050712212026.5bd2dbbb.pierre@dotgeek.org> <42D42430.5060001@prohost.org> <20050712161703.rf2hn68dptcswssw@marina.horde.org> In-Reply-To: <20050712161703.rf2hn68dptcswssw@marina.horde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 82.1.27.86 Subject: Re: [PHP-DEV] php 4.4 BC break From: nick.telford@ntlworld.com (Nicholas Telford) Firstly, a major version number increment implies a major change (4.2.0 and 4.3.0 had much more major changes than this iirc). Secondly, as far as I'm aware, it doesn't issue a warning, it issues notices which, and this has been stressed on many occasions, should not be displayed on production servers. Lastly, there IS a note in the announcement stating that the major version increase is due to a non-BC change, I don't see what everyone is complaining about. Perhaps you should request that your users read what they're downloading before they download it. Just my thoughts. Nicholas Telford Chuck Hagenbuch wrote: > Quoting Ilia Alshanetsky : > >> In this case the "facility" was implementing, poorly might I add a >> handler for a clearly incorrect behavior. Removing it was not only >> appropriate but necessary to encourage proper code being written. > > > I know that other people have other points of view, but I am not arguing > this. I'm just asking that 4.4 be marked as having a non-BC change, > because - whether I could have updated my new code or not - there's a > ton of existing code out there that will never magically change to run > silently under 4.4. > > I've already had people running old major versions of applications > upgrade to PHP 4.4 because it has "security fixes", and then come > complaining because suddenly they get a ton of warnings. > > Yes, they could turn off warnings. But since the code has always run > cleanly beforehand, they don't think to do that. > > Yes, they could very well ignore a note on php.net about the code > they're downloading. > > But if there *was* a note with the 4.4 release, it would somewhat > lighten the load on PHP application developers dealing with the change. > > -chuck >