On Sat, Feb 21, 2009 at 1:05 PM, Marcus Boerger <he...@php.net> wrote: > 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.
In your mind maybe, but if we do not follow these simple rules then we have a serious problem. > 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. We have been wrong in the past and changed API between minor version, it was a major mistake. In the meantime, we have tried to do not do it again. x.y.z and x.y.y+1 has not only have to keep the same sematic, behaviors but also the same signatures as well as a binary compatibility. One bad example was a change we made in 5.2.x making it incompatible with previous versions, there was no version id chante and it was a pain to change the extensions to be compatible with the full 5.2.x serie. The worst is that I can't even figure out when it happens without looking at the code (maybe 5.2.5? :) > 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. That's no problem, as long as the x.y.z+1 API is 100% compatible with x.y.y. New functions do not break existing functions signature or behaviors, obviously. > 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, ABI has to do with the discussions as a given binary has to work across the same minor versions. It causes the same problem but with different origins. > 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. Exactly what I said. New functions do not break the API and it is possible to modify a struct without breaking existing binary compatibility. > The new patch is clean enough to me and doesn't change the API. Whether the > ABI changes depends on the compilers and linkers. My comment was a general comment on what should be the policy, not specifically about this patch :) All in all it seems that you are saying the same than I did, only with different wording :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
