Bug #65948 [Wfx]: extension and PHP API version mismatch

From: Date: Thu, 24 Oct 2013 23:04:35 +0000
Subject: Bug #65948 [Wfx]: extension and PHP API version mismatch
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-182459@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=65948&edit=1

 ID:                 65948
 Updated by:         yohgaki@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:

Just an additional note for Linux distributions.

AFAIK, all Linux distributions have strict version match policy for modules. This is not a PHP
limitation, but distributor's limitations. (e.g. Modules built with PHP 5.5.5 requires PHP
5.5.5, not 5.5.x.) They add strict version dependency even if PHP itself does not require it.

You don't have to follow Linux distributors limitation.


Previous Comments:
------------------------------------------------------------------------
[2013-10-24 22:55:16] yohgaki@php.net

PHP script is the "application". PHP is the "OS" for PHP applications.

Linux applications run on very long term as well as PHP applications. libc is like a framework that
wraps incompatibility between PHP versions.

If you use NVidia native driver for X, you'll notice that Linux kernel changes internal API/ABI
often and source code has to be modified. Internal API/ABI needed to be changed to fix bugs and
improve features, performance, etc.

If you would like to provide modules work under versions of PHP, for instance 5.3.x, 5.4.x and
5.5.x, you only have to maintain 3 binaries for 5.3.x, 5.4.x and 5.5.x. To keep compatibility
between 5.3.x, 5.4.x and 5.5.x, you will needs only handful #if/#ifdef and no need for 3 sources but
one. It should not be hard jobs for C programmers.

------------------------------------------------------------------------
[2013-10-24 22:35:46] nikic@php.net

Thanks for your insights as to how not providing ABI-compatibility on par with operating systems
results in "worst of any computer programming language API/ABI's compatibility"
(because operating systems are the same as programming langues, obviously).

PHP provides about the same guarantees that Python does: API/ABI compat for x.y.z+1 and
mostly-source-compat for x.y+1.z.

------------------------------------------------------------------------
[2013-10-24 22:13:08] wzis at hotmail dot com

Not very true: On UNIX/Linux systems, you can still have multiple versions of libc installed at
different locations if that is really you need, and you can let a program to use the version of libc
by setting LD_LIBRARY_PATH: but since on UNIX/Linux systems, the API backward compatibility is
maintained very well, there is no such need to install a different version of libc in normal
situation.
On Solaris, a program binary built on Solaris 8 can still work on Solaris 11, that's more than
15 years in time span.
As for ABI compatibility, even freebsd wants to make ABI compatible with Linux.
So the PHP's way of only maintaining API (in your sense may be ABI, but this is even on same
platform even with same OS version) compatibility within just the x.y.z for all z, that's the
worst of any computer programming language API/ABI's compatibility.

------------------------------------------------------------------------
[2013-10-24 10:55:17] johannes@php.net

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

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

------------------------------------------------------------------------


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


Thread (15 messages)

« previous php.bugs (#182459) next »