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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list