Hello Pierre, Thursday, February 19, 2009, 12:22:41 PM, you wrote:
> hi, > On Thu, Feb 19, 2009 at 11:57 AM, Johannes Schlüter <johan...@php.net> wrote: >> ps. I'm aware of the fact that we added some specific APIs in special >> cases in bug fix releases before, but there's a difference between >> adding APIs and breaking the ABI of existing, used, stuff. > Exactly. To summarize: > x.y.z to x.y.z+1: ABI and API must be 100% compatible > x.y.z to x.y+1.z: ABI can be broken (need a recompilation), API must > be 100% compatible > x.y.z to x+1.y.z: party time ;) That's completely untrue. What we ensure is that function f introduced in x.y.z stays in all verisons x.y.z+n and keeps its exact semantics. What we did not ensure ever, is that version x.y.z+1 does not come with a function g that did not exist in x.y.z. Same obviously applies to consts and yes macros, which have nothing to do abi or api. And actually abi has nothing to do with the whole discussion. The ABI influences how a binary gets layout, and in that way determines how a user of said binary can access the API elements (consts, function, classes,...). This obviously affects DLLs on windows and shared objects on *nix. Either way, adding more macros and new functions is fine, as lone as we do not change any existing function protocol. The new patch is clean enough to me and doesn't change the API. Whether the ABI changes depends on the compilers and linkers. > Cheers, Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
