Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h
At 08:38 02/08/2001, Thies C. Arntzen wrote: On Thu, Aug 02, 2001 at 07:09:35AM -0700, [EMAIL PROTECTED] wrote: On Thu, 02 Aug 2001, Zeev Suraski wrote: zeev Thu Aug 2 09:16:20 2001 EDT Modified files: /Zend zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h Log: Some cleanup I really wish all these TSRM changes were left for 4.1. There are just way too many functions affected and I guarantee you that all the standalone extensions will be broken because people will not expect such breakage from a point release. It also breaks binary compatibility forcing everyone to release new extensions. The change from ZEND_API void wrong_param_count() to ZEND_API void zend_wrong_param_count(TSRMLS_D) Makes extensions built for 4.0.6 break against current CVS right now: PHP Warning: Unable to load dynamic library '/usr/local/lib/php/php_ming.so' - /usr/local/lib/php/php_ming.so: undefined symbol: wrong_param_count in Unknown on line 0 binary compatiblity was already broken some time ago in the 4.0.7-branch. right now we have also lost source-code compatiblity due to the TSRM stuff, i think we should try to get at least source-code compatiblity back before we release 4.0.7. zeev, any idea what would be needed to do that - or is that already on your list? No, it's not on my list. Source code compatibility for the thread-safe mode isn't very important in my opinion, but I'll probably take a look at it myself next week anyway. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h
On Thu, Aug 02, 2001 at 07:09:35AM -0700, [EMAIL PROTECTED] wrote: On Thu, 02 Aug 2001, Zeev Suraski wrote: zeev Thu Aug 2 09:16:20 2001 EDT Modified files: /Zend zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h Log: Some cleanup I really wish all these TSRM changes were left for 4.1. There are just way too many functions affected and I guarantee you that all the standalone extensions will be broken because people will not expect such breakage from a point release. It also breaks binary compatibility forcing everyone to release new extensions. The change from ZEND_API void wrong_param_count() to ZEND_API void zend_wrong_param_count(TSRMLS_D) Makes extensions built for 4.0.6 break against current CVS right now: PHP Warning: Unable to load dynamic library '/usr/local/lib/php/php_ming.so' - /usr/local/lib/php/php_ming.so: undefined symbol: wrong_param_count in Unknown on line 0 binary compatiblity was already broken some time ago in the 4.0.7-branch. right now we have also lost source-code compatiblity due to the TSRM stuff, i think we should try to get at least source-code compatiblity back before we release 4.0.7. zeev, any idea what would be needed to do that - or is that already on your list? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h
It should be fairly easy to support both codebases by just defining the right things depending on the API_NO. At any rate, whether we call it 4.1 or 4.0.7 doesn't really matter. It had to be done, and would involve the same kind of issues regardless of the name. Zeev At 06:47 02/08/2001, Andrei Zmievski wrote: On Thu, 02 Aug 2001, Andrei Zmievski wrote: I really wish all these TSRM changes were left for 4.1. There are just way too many functions affected and I guarantee you that all the standalone extensions will be broken because people will not expect such breakage from a point release. Oh, as an example PHP-GTK v0.1 now has to require latest PHP CVS or 4.0.7 because of this. Not too good. -Andrei The only true currency in this bankrupt world is what we share with each other when we're uncool. -- Lester Bangs, from the film 'Almost Famous' -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h
At 10:40 02/08/2001, Jani Taskinen wrote: True. So you're saying that the people who write extensions should also be following [EMAIL PROTECTED] to know about any major changes? I guess most of them are; Those who aren't will bump into these issues as soon as they try to upgrade. It's not something that'll bite them at runtime. - For the register_globals default change, I believe a major version bump is a very good idea, as it's exactly the kind of heads-up message we want to send to all of the users. Of course. btw. When do we get the nice, short names for the HTTP_*_VARS? Sometime soon :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h
The work which will have to be done is the author, not all of the users. So the 10K number is not all that relevant. At 10:50 02/08/2001, George Schlossnagle wrote: Yes, I was counting those too... It's still not a very large number (probably in the range of dozens, or hundreds at the most, compared to hundreds of thousands of users). Conservative estimates put the APC user community at just below 10,000 people. I'm sure it's not the most popular 3rd party php extension out there. Both binary and source compatibility will have good warnings for developers and users (binaries will not load, source will not compile...), so there should be no real obscure-crashes type of problems. I don't think the obscurity of the crash was at issue, just that a minor version bump-up would break an end-users install at all. I don't know, it seems to me that bumping a version number because of an API change which is transparent to end users is a bit odd, but if most people think otherwise, it's very much possible... Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
