I developed the extension on RHEL 5.5 with PHP 5.1.6, and put the extension .so to RHEL 6.4 with PHP 5.3.3, and the extension failed to load due to VERSION of PHP API mismatch.

We keep binary compatibility for all z in x.y.z version numbers.

We only keep API compatibility for "minor" version. That's the way it is.

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.

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?

If we only use very minimum PHP API functions and data structures, is there a way to achieve build once, run on multiple versions?

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)

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.

If glibc follows the PHP in way of doing API compatibility, it will be nightmare for 3rd party software developers.

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

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.

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.

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.

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.

It's not that simple to just have 5 modules for 5.1, 5.2, 5.3, 5.4, 5.5: for AIX/HP-UX 9000/IA64/Solaris Sparc/X86, Linux X86/ARM/Power, that means we have to maintain 40 modules, in stead of just one module for each platform, and in total just 8.
Yes, Linux kernel does change very frequently, but for commercial Linux, like RHEL, they know this is a problem, so they will try to maintain the kernel API/ABI compatibility within each major release as much as possible, they won't just get a latest kernel from the kernel.org and let user to upgrade the kernel like that.

Well, we're going in circles: From our side we see the issue but don't prioritize it in our work high as most of us distribute source (btw. my employer has binary PHP extensions as had my previous so I know the trouble) and the wide API we have offers benefits to do "magic".

If you are interested in picking those RFCs and create a stable API which allows typical extensions (exporting functions, constants, classes, ...) we're happy. If not this won't happen in a foreseeable future. No need for further circles.