Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A495AB00F@il-ex2.zend.net>
References: <1314115682.2635.98.camel@guybrush>
	<4E545A6C.60704@akbkhome.com>
	<CAH-PCH5jyEQZvwgqxkUpqN7a-VUc+nYt=_ixFQ1si64xxMBw4A@mail.gmail.com>
	<4E54C658.6070209@akbkhome.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AAA2F@il-ex2.zend.net>
	<CAEZPtU4TQ_-FnrqosWfLx8xvQvgtPi2BnhkV3o=J43056Lxoeg@mail.gmail.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AAE17@il-ex2.zend.net>
	<CAEZPtU5Hy6rqbj0DMVg+HhJ2yMoSA2O4ErNpwbe0JuKc0t=jrw@mail.gmail.com>
	<887FE7CFF6F8DE4BB3A9535F53AFD06A495AB00F@il-ex2.zend.net>
Date: Wed, 24 Aug 2011 14:12:17 +0200
Message-ID: <CAEZPtU7MLoH=vQ2S12keYtPtoQT9fDb9YLQrF4qOSU=iA0M+nw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Aug 24, 2011 at 2:00 PM, Zeev Suraski <zeev@zend.com> wrote:
>> > This wholesale statement doesn't get us anywhere.
>>
>> It does, we underestimate the situation and this fix/improvement/consist=
ency
>> change breaks apps and codes out there.
>> And I do not consider it as acceptable at this stage in 5.3.x. Let do it=
 only in
>> 5.4.
>
>
> How is it different from any of the other non-crash-fixing bugs we fixed,=
 that could break apps that relied on the old behavior? Gave you two exampl=
es from the last release (well, 5.3.7), and another imaginary one. =A0They =
all fall in the category of potentially breaking code out there, and yet - =
they should all be fixed.


Zeev, the whole point is that changes like this one must be discussed
on a case by case basis. It is now very well known that when a fix
requires a test change, then it often leads to bc breaks or similar
issues.

I do not think we have to argue about the semantics or general cases
but how to avoid such things and be sure that we break as less code as
possible in patches release.

It is also obvious, as you stated, that there will have edge cases
where we have to break existing codes, for security or critical
reasons. This is definitively not the case here.


--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org