Re: Next release

[Helge Hess]

BTW: sometimes people don't know what ABI compatibility implies in the  
real world. The basic idea is that if I have a library and a tool, I  
can replace 'library' with any ABI compatible library and the tool  
still works. Stuff like crasher bugs being fixed.

Say, I have installed
gnustep-base 0.13.0
SOGo 0.7.3

If gnustep-base 0.17.0 would be ABI compatible to 0.13.0, I could just  
replace it and SOGo 0.7.3 would still work. This is much harder than  
API (not ABI) compat with 0.7.3. The latter only requires that I can  
recompile 0.7.3 against the new API version (fragile baseclass is just  
a small part in this scenario).

A simple (admittedly constructed) example: lets say gnustep-base  
0.13.0 had:
  @interface NSObject
  ...
  - (BOOL)isNotEmpty;
  @end

Well, and SOGo might have choosen to *override* that method using a  
category. Which is perfectly valid in ObjC:
  @interface NSObject(SOGo)
  - (BOOL)isNotEmpty;
  @end

Now gnustep-base 0.17.0 might have said: well, isNotEmpty really does  
not belong to NSObject!, lets refactor it! and move it to a category:
  @interface NSObject(GSAdditions)
  - (BOOL)isNotEmpty;
  @end

Hey! We just b0rked ABI compat :-) SOGo's implementation of - 
isNotEmpty won't get used anymore, even though it worked just fine  
before.


Apple's frameworks are in fact ABI compatible this way (well they  
sometimes have bugs in that, but overall they have great ABI  
compatibility).


ABI compat bascially means you are not allowed to touch the code  
except in *very* well defined ways. (eg Apple reserves the NS*  
namespace, so they are 'allowed' to add classes and still have ABI  
downwards compat).

Greets,
  Helge