at-spi versioning



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?

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?

regards,

Bill






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]