RE: [PHP-DEV] PHP 5.3.8 Released!

From: Date: Wed, 24 Aug 2011 12:50:56 +0000
Subject: RE: [PHP-DEV] PHP 5.3.8 Released!
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-54878@lists.php.net to get a copy of this message
Well, I have to admit this is mighty convincing :) Wasn't aware of this use-case. Falls under the category of mass breakage I guess. Zeev > -----Original Message----- > From: alan@akbkhome.com [mailto:alan@akbkhome.com] > Sent: Wednesday, August 24, 2011 3:39 PM > To: Zeev Suraski; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.3.8 Released! > > " If it's a clear bug, which IMHO this is_a() issue was - then unless we're > looking at code breakage at massive scale, it should be fixed. " > > mmh.. how much breakage did you want. > > PEAR::isError is basically is_a($input, 'PEAR_Error'); it's been like that for > > 8 > years.... > > google search for PEAR::isError shows 16,600 matches.. > > > http://www.google.com/codesearch#search/&q=PEAR::isError%20lang:php& > type=cs > > <http://www.google.com/codesearch#search/&q=PEAR::isError%20lang:php > &type=cs> > > for is_a you get 149K. and this is only public code... > > It's big... Luckily quite a few people are on holiday this month and will not > upgrade too soon. > > Regards > Alan > > > > On Wednesday, August 24, 2011 08:22 PM, Zeev Suraski wrote: > > > > It has nothing to do with security (criticality is subjective so I'm leaving it > aside). The 3 bugs I mentioned (2 from 5.3.7 and one imaginary) have nothing > to do with security, and yet we fixed them (or would have fixed them), despite > the potential for people out there relying on the old behavior. It boils down to > evaluating the severity of the bug and the likelihood that it'll break code. If it's > a clear bug, which IMHO this is_a() issue was - then unless we're looking at > code breakage at massive scale, it should be fixed. > > > > Again, I'm almost religious about retaining compatibility (even across major > versions), but if we had a piece of code that was returning clearly the wrong > value, we can't ignore it because some (my guess very few but who knows) > relied on this behavior. > > > > Zeev > >

« previous php.internals (#54878) next »