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
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.