Peter N. Lundblad wrote:
>>>That's an ABI change in a public interface so it's not acceptable.
>>>You need to retain svn_commit_callback_t and provide a new name,
>>>svn_commit_callback2_t say, with the new parameter.
>>
>>Whats ABI? I think all functions, pointers that comply to
>>svn_commit_callback_t have been touched in this patch. However, I
>>understand the client-server version compatibility issue. Is this your
>>concern. Could you please explain your concern with an illustration ( a
>>scenario ) so that I can make changes with an inherent understanding...
>>this would also be a learning for me. Thanks.
>
> ABI means Application Binary INterface. It includes things as function
> calling conventions (in what order arguments are put on the stack, where
> the return value is placed etc.) and other things that ensures binary
> compatibility. When *we* talk about ABI breakage we mean that code linked
> to one version of the library will not work with a later version. Adding
> (or removing or changing) the arguments to a function is obviously an ABI
> change; it will make the program crash or something similar. Changing the
> contents of a structure is often an ABI change (some might argue it always
> does). Read more about our compatibility rules in HACKING.
Also, Garrett Rooney wrote an excellent ONLamp article about backward
compatibility here:
http://www.onlamp.com/pub/a/onlamp/2005/02/17/backwardscompatibility.html
It talks about API and ABI compatibility, and specifically uses the
Subversion project as an example, since he's a Subversion developer.
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Received on Thu May 12 17:20:09 2005