On 04/09/2010 07:41 AM, Chris Lalancette wrote:
> Caveats:
> 3)  Application developers will be strongly discouraged from using
> this API because of the above 2 issues.  To help in this, the
> API's will be in a separate library that developers will explicitly
> have to link to, and it will have a different (but largely compatible)
> wire protocol.

Providing two side-by-side libraries under the libvirt package umbrella
makes sense to me, but it means we need to start thinking more seriously
about library version numbers.  See
https://www.redhat.com/archives/libvir-list/2010-April/msg00226.html for
some food for thought; in particular, the idea that since we create our
library (or libraries, after this proposal is enacted) via libtool, we
should be using the libtool versioning scheme for the .so files, which
would be independent from the libvirt package number.  It is entirely
feasible to have a release that increments the version number of one but
not both .so, or which increments them in different manners (libvirt
increasing current and age, because it added new APIs but is still
backwards compatible, while the helper library resets age to 0 because
it added a backwards incompatible change).

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org