Hello Pierre, Saturday, February 21, 2009, 2:46:01 PM, you wrote:
> 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. And so what are you writing here? I explained to him the exact terms under which he can add the function. And his patch actually followed these terms as far as I could see. >> 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 :) erm, oh right :-) > Cheers, Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
