Zeev Suraski wrote: > At 17:10 30/05/2005, Derick Rethans wrote: > >> Not fixing it is *not* an option. You fix something that's broken - you >> don't leave it broken. That's called responsibility. And no, switching >> to PHP 5 is not an option either. > > > Sorry Derick, but you saying that not fixing it and/or that switching to > PHP 5 are not valid options doesn't mean that they're not valid > options. I think that with the rarity of this issue and even higher > rarity of it actually causing problems, taking this approach is > extremely valid. Breaking binary compatibility inside a 'PHP version > family' on the other hand is not an option, we've decided not to do this > 3 or 4 years ago, and I don't see any reason to break this decision at all. > > I for one think that (a) providing info and workarounds, and (b) > pointing people to use PHP 5 is a completely acceptable solution to a > problem of this magnitude, when compared to the cost of fixing it. > Let's see what others think.
If we have a fix, we should get it to our users. Personally this problem has been haunting me for quite a while now and I will be deploying the patch and happily breaking binary compatibility as soon as Derick and Marcus tell me it is ready. A binary compatibility break is annoying, but once I recompile all the revevant extensions, the millions of lines of existing PHP4 code will run unchanged and with fewer crashes. The migration to PHP5 is a longer term effort that requires all the domxml code to be rewritten, for one, about 140 custom extensions need to be reviewed and some of them heavily modified, APC needs an update and the existing PHP4 OO code needs to be reviewed. There is no way I am going to not deploy a PHP4 crash fix in order to speed up the transition to PHP5. I have a schedule for that which isn't going to change and in the meantime anything I can do to improve the current situation, I will do. And yes, while I realize my specific environment is not exactly representative of the world at large, I also don't think that other folks out there are all that different. I think many people rely heavily on the packages maintained by the various Linux distributions. A binary compatibility break is a burden on the maintainers of these packages, but beyond needing to update every PHP package, the end user really isn't burdened by it in any way unless they have their own custom extensions, or if they have pecl extensions installed, they'll need to grab them again from pecl and build against the new dev files. If the cost of fixing this is purely on us and a handful of distribution maintainers with minimal cost to the end users, then I think the choice should be simple here. Asking Joe Orton and the various other package maintainers from the major distros might be a good idea too. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
