Noteworthy changes in version `1.9.2'
=====================================
* GSMime parsing ignores extraneous data
* New log functions GSOnceFlag and GSOnceMLog
* New class NSError
* Multiple new function in GSObjCRuntime
* NSProtocolChecker rewritten
* autogsdoc support added for building frames
* Binary incompatibility: NSUnarchiver, GSIMapTable have new ivars
added
I notice there is a binary imcompatibility, and that the soname is
still libgnustep-base.so.1 (objdump -p libgnustep-base.so.1.9.3 | grep
SONAME).
Why ?
Isn't there a rule that say:
If a package keeps the same SONAME, it means that the BINARY
COMPATIBILITY IS KEPT.
Why is it annoying ?
For example, in debian, when gnustep-base-1.9.2 will replace
gnustep-base-1.9.1(soon), all apps using NSUnarchiver, GSIMapTable
won't work any longer and users will have to wait that maintainers of
these apps rebuild them. (And imagine that sarge is released before
these rebuild...).
But if the soname was bumped up (lignustep-base.so.2 or
libgnustep-base-1.9.2.so.1 for example), I could provide two packages
: libgnustep-base1 and libgnustep-base2 (or libgnustep-base-1.9.2-1)
that could be installed in parallel and all apps will work fine even
if their maintainers forget to rebuild them. It seems really a better
solution.
So please can you review your policy about libraries versionning to
help package maintainers (and thus your final users) ?
Eric
I suggest to read this: (chapter 4, 5 & 8)
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-
guide.html#SONAMES
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep