On Oct 5, 2006, at 24:30, Hubert Chan wrote:
I would prefer to have more frequent releases, but with a stable
SONAME/ABI.
Thats an obvious contradiction. Its close to impossible to advance
the functionality w/o changing the ABI. If you have set an ABI its
set in stone, you can only provide bugfixes.
(you never need to recompile programs for a new release if you keep
the old libraries ... that's what library versioning is for)e
.
[users do NOT compile programs, developers do]
Actually, with the recent GNUstep 0.11.0/1.13.0 release, you are
unable
to run programs compiled against 0.10.3/1.12.0 because the old library
could not communicate with ... I think it was gdnc (I assume due to a
change in the communication protocol).
...
On the other hand, if you take a program compiled against
0.10.3/1.12.0
and make libgnustep-base.so.1.12.0 a symlink to
libgnustep-base.so.1.13.0, and libgnustep-gui.so.0.10.3 a symlink to
libgnustep-gui.so.0.11.0, it seems to run perfectly fine.
Thats because the program you check only uses the "old" API. ABI
compatibility is _exact_. You can't add a (public) class or method
and you must not "fix"(/change) the behaviour in an incompatible way.
Eg if gnustep-base 1.13.0 adds NSOutputStream and a tool uses that it
can't be ABI compatible with 1.10.0 for obvious reasons.
So keeping a stable ABI bites with advancing gnustep-base which is
often work for adding additional Cocoa methods, classes or fixing
incompatible behaviours etc.
Which is why I _encourage_ having more GNUstep _alpha_ releases to
move things forward quickly in the release-early-release-often
spirit. But at the same time its not really hard to keep _one_
maintained and published "guaranteed" state a "thirdparty" developer
can rely on.
Greets,
Helge
--
Helge Hess
http://docs.opengroupware.org/Members/helge/
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
