Re: ANN: GNUstep Gui Version 0.9.4

[Helge Hess]

On Oct 1, 2004, at 23:13, Adam Fedor wrote:
> I should probably write up a policy about this somewhere, but... 
> libtool says you shouldn't try to relate the soname and the release 
> version because they have nothing to do with each other.

This is not really a 'policy' but a technical requirement, it is how 
ld.so versioning works. The same soname implies that the libraries are 
100% API compatible, if you add a class or add/remove methods, change 
signatures etc, you need to change the soname.

> I'd consider that strange reasoning, but anyway - my policy from now 
> on is that they will be related. Changes in the major or minor release 
> version indicate some kind of interface change in the library. 
> libtool's versioning system is interesting, and we might consider it 
> for the future,

This has nothing to do with libtool, its how ld.so/ld works. If you 
want to see GNUstep packages in the mainline of distributions will have 
to ensure that sonames are correct. I think this is in the policy of 
basically every Linux distribution.

> but first some facts:
> 1. The current GNUstep-make policy for all libraries is that the 
> SONAME consists of the library name and the major version number.
> 2. That's not very fine-grained for me, so I've changed that policy 
> for base/gui so that it also has the minor version number in it.

We always used the major/minor as the soname for SOPE/OGo/SKYRIX. The 
basic idea is that all alpha versions (1.1 or 4.3) do not need to 
ensure that the API is compatible (those alpha versions will never hit 
a mainline distro).
In a release version (1.0 or 4.4) API is strictly forbidden to change. 
No additional classes and _no_ additional (public) methods. Changes 
need to wait for the next release.

Advantage: you don't need to track API compatibility. We just increase 
the soname to the stable release version whether or not they are 
compatible. (eg a 4.4 SOPE library like SaxObjC is often perfectly API 
compatible to 4.2).

Disadvantage: all thirdparty tools have a hard time because they need 
to resubmit for each and every minor version (even if those happen to 
be compatible). Because of this you also want to embed the soname in 
the RPM/Deb package name, so that an older tool(/package) compiled 
against v1.6 can be installed at the same time with a newer 
tool(/package) compiled against v1.8.

Well, of course all this is only important if someone else is using 
your software and you need to maintain stable packages for inclusion in 
a distro ;-)

Greets,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org