On Tuesday 23 November 2004 11:02, Zeev Suraski wrote: > At 17:40 20/11/2004, Marcus Boerger wrote: > >Hello Wez, > > > > unfortunatley this fix is needed to make __call() being executable in C. > > Yes, but the question is whether it's important enough to break binary > compatibility because of that. Being able to use __call() in C can > definitely be considered a new feature which should make it only into 5.1, > considering it requires everyone to fix their modules and anybody using > shared libraries to recompile them. We haven't been doing that in bugfix > dot releases since 4.3, so if we do it now it would be the first time in > almost two years. (It's not that we didn't want to, by the way - but with > the concept of PECL gaining momentum, breaking binary compatibility in > between bugfix releases just makes no sense). > I looked into the CVS history - binary compatibility was only broken by the > get_method signature, nothing else. IMHO, we should revert the change and > introduce it only in 5.1.
I have to agree with this. The concept of PECL windows binaries depends on the fact that PHP extensions are binary compatible among patchlevel versions. I guess authors of propriatory PHP extensions would face the same problem. If we absolutely need to fix this, prior to 5.1.0 release the only responsible thing to do would be to rename 5.0.3 -> to 5.1.0 and move HEAD branch to 5.2.0. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
