Edit report at https://bugs.php.net/bug.php?id=65948&edit=1
ID: 65948 Updated by: johan...@php.net Reported by: wzis at hotmail dot com Summary: extension and PHP API version mismatch Status: Wont fix Type: Bug Package: *General Issues Operating System: Linux PHP Version: Irrelevant Block user comment: N Private report: N New Comment: First: Please don't confuse ABI and API compatibility. API compatibility we have to a way larger degree. So many things just need a recompilation. ABI, binary compatibility is what we are talking about. Yes, operating system core APIs have quite some restrictions on ABI compatibility, this leads to some maintenance hell in some areas like use of special #defines to enable specific features or bug fixes or ... There the restrictions make sense - you can run only one libc on a host. With PHP this isn't the case. That said: We are aware of the fact that we might do better by having a stricter defined API and keeping that stable. For none of the active contributors (who are volunteers) this is not a big issue, though. If you want to help in that area this is welcome. Some basic thoughts are in these RFCs: https://wiki.php.net/rfc/php_native_interface https://wiki.php.net/rfc/remove_zend_api Previous Comments: ------------------------------------------------------------------------ [2013-10-24 00:16:35] wzis at hotmail dot com If glibc follows the PHP in way of doing API compatibility, it will be nightmare for 3rd party software developers. ------------------------------------------------------------------------ [2013-10-24 00:12:25] wzis at hotmail dot com But API should be very stable: one example is glibc: even though it has been many version releases, but so long you compile a program on a version of glibc, and only run that binary on system with that version of glibc or newer, the program can run successfully. ------------------------------------------------------------------------ [2013-10-23 23:12:09] johan...@php.net If you want to do experiments in that area you could do magic by creating your own get_module() function which detects the PHP version, but we change structures as we see need between releases. You are mentioning 5.1 versus 5.5 that's 8 years of development work with lots of improvements. We care a lot about binary compatibility between bug fix releases (x.y.z++) but not feature releases (x.y++.z) ------------------------------------------------------------------------ [2013-10-23 23:00:34] wzis at hotmail dot com If we only use very minimum PHP API functions and data structures, is there a way to achieve build once, run on multiple versions? ------------------------------------------------------------------------ [2013-10-23 22:56:13] wzis at hotmail dot com What do you mean by "Please use #if #ifdef to make your module built with versions. I personally have module that works from PHP 4.3 through master, you should be able to do that." Do we still need to build the module for each version (x.y) or by using the #if #ifdef now we can build module on one version, use it on newer versions? Any example? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65948 -- Edit this bug report at https://bugs.php.net/bug.php?id=65948&edit=1
