On Wed, Aug 24, 2011 at 2:00 PM, Zeev Suraski <z...@zend.com> wrote: >> > This wholesale statement doesn't get us anywhere. >> >> It does, we underestimate the situation and this fix/improvement/consistency >> 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 examples > from the last release (well, 5.3.7), and another imaginary one. They 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. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
