qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Bumping the soversions...
Date Fri, 02 Nov 2012 18:02:26 GMT
On Fri, 2012-11-02 at 11:39 -0400, Darryl L. Pierce wrote:
> In going through the packaging for Fedora, I found a disconnect between
> the soversions for our libraries as declared in the build systems in our
> repo and what Fedora is assigning to each. I bumped the versions in
> CMake to match what's declared in Fedora and pushed before raising the
> issue here.
> What we had previously was:
> ------------- -------- ------
> qmf           1.0.0    4.0.0
> qmf2          1.0.0    1.0.0
> qmfconsole    2.0.0    5.0.0
> qmfengine     1.1.0    4.0.0
> qpidbroker    2.0.0    5.0.0
> qpidclient    2.0.0    5.0.0
> qpidcommon    2.0.0    5.0.0
> qpidmessaging 2.0.0    4.0.1
> qpidtypes     1.0.0    3.0.2
> rdmawrap      2.0.0    5.0.0
> sslcommon     2.0.0    5.0.0

My recollection of previous discussions is this (someone else might have
a better recollection):

Nearly all of those libraries are purely for internal use in qpid
executables/libraries and are not meant to be exposed to developers to
link against. Ideally these libraries wouldn't even be in /usr/lib[64]
at all. This includes qpidbroker, qpidcommon, rdmawrap, sslcommon. I'm
not sure about the various qmf libraries, but I think only qmf2 is
current anyway. Since these are purely internal the soversion is
irrelevant since we make absolutely no ABI guarantee at all - in fact it
would make sense not to include soversions as you HAVE to use the
library that you compiled for the version of qpid you are using.

qpidclient is a possible exception to the above in that, ideally it is a
purely internal library now, only being used in the implementation of
the qpidmessaging API and deprecated for direct use. However even there
it is clear that the qpid upstream has not changed the so version. And
it looks like Fedora has revved the number just once for incompatible
changes to the API/ABI. This makes me think that no one s really paying
attention to the library compatibility for this library.

The only libraries which are presently intended to have a stable API and
therefore a controlled ABI are qpidmessaging and qpidtypes as far as I
know. For these libraries and I think for these ones only we do need to
manage the soversions a little carefully with respect to interface

So after all that long winded explanation here is the TL:DR:

There are a few possibilities -

* [My preferred option] The qpid upsteam should not worry about
soversions AT ALL and leave it for downstream to get right. In this case
we just leave the soversions as they are "forever" and downstream needs
to patch them as necessary. This is the current status.

* We unversion the internal only libraries to avoid the suggestion that
the soversion might indicate something for them. If possible we move the
libraries away from /usr/lib[64] to stop them being visible for
developers linking against them.

We then rev the qpidmessaging/qpidtypes soversions to something higher
than everyone is currently using to indicate a break of compatibility
and we start carefully enforcing soversion bumps when we make non
backward compatible ABI changes (and minor bumps when we make any

Major problem here is that we don't have upstream tools (that I know
about) to warn us of any ABI changes. Downstreams have some tools for
this though. So enforcing the version bumps will be hit and miss.

-- Justin as release manager through the past few releases do you have
any thoughts to add?


To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message