Re: at-spi versioning

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-04-17 at 13:38, Bill Haneman wrote:
> Hi:
> 
> I have a quick (and also a not-so-quick) question about versioning for
> at-spi's libraries.
> 
> Quick question:
> 
> I'd like to move away from the gtk+-style versioning libtool rules to
> something simpler.  Is it OK for me to change the 'minor number' in the
> .so filename thusly:
> 
> .so.0.0.X : (current)
> .so.0.1.X : (HEAD, i.e. gnome-2.3)
> .so.0.2.X : stable gnome-2.4
> 
> etc.?  IOW is there any reason to increment only the revision even after
> a branch?

Note that you can't really control the soname to this level of detail
with libtool. You should be able to get the minor number to be the
same within each stable branch, but controlling the exact value isn't
feasible.

You can pick current:revision:age to get whatever numbers you want
on Linux and Solaris, by reverse engineering the libtool algorithm,
but if you do that, then you will not be portable across all
libtool platforms platforms. If you consider the GTK+ scheme too
complex, then you should read and follow what's described in the libtool
manual.

> The above scheme would allow for monotonically increasing releases on
> concurrent branches, without resorting to high revision numbers.
> 
> Anyone see a problem with this scheme?
> ----------
> 
> #2 = not-so-quick question:
> 
> Due to an unfortunate screwup on my part, the at-spi library sonames
> were released with an incremented major number a while back. 
> Unfortunately RH8 shipped with libspi.so.1.X.X, whereas the soname
> looped back to zero where it should have been, e.g. thereafter the
> soname series has been libspi.so.0.0.X.  What should we do about this;
> should we consider taking the pain now by changing the soname to
> something > 1.0.X, so that the obsolete libspi is forever left behind by
> libtool?  Or should we just tell developers to remove the old libspi if
> they are on RH8 or another platform that grabbed the .so.1 library?

Forcing soname numbers to make them artificially match some external
expectation of what they should be is almost always wrong.

Going backwards on soname versions is *alway* wrong.

If you released tarballs of ati-spi that had a major of 1, and have
since broken binary compatibility, you _must_ use a major of at
least 2 now.

(The complexities of the GTK+ scheme are meant to make the soname
somewhat human-readable, if you consider gtk+-x11-2.0.so.0.200.0.1
human-readable. There are simpler schemes, such as the straight
libtool scheme, that work. But trying to make your sonames match
a simple definition of simple will just make everybody trying 
to package your library hate your guts.)

Regards,
                                         Owen