From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0KUU-0001YN-CW for qemu-devel@nongnu.org; Fri, 09 Apr 2010 16:07:46 -0400 Received: from [140.186.70.92] (port=52170 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0KUT-0001XX-4N for qemu-devel@nongnu.org; Fri, 09 Apr 2010 16:07:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0KUR-0006FC-GW for qemu-devel@nongnu.org; Fri, 09 Apr 2010 16:07:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38881) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0KUR-0006F3-5q for qemu-devel@nongnu.org; Fri, 09 Apr 2010 16:07:43 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o39K7fCa030528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Apr 2010 16:07:41 -0400 Message-ID: <4BBF8911.8020104@redhat.com> Date: Fri, 09 Apr 2010 14:07:45 -0600 From: Eric Blake MIME-Version: 1.0 References: <4BBF2E93.3020508@redhat.com> In-Reply-To: <4BBF2E93.3020508@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF29E439ECC627D5F1DA3243" Subject: [Qemu-devel] Re: [libvirt] Libvirt debug API List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Lalancette Cc: Libvirt , Jiri Denemark , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF29E439ECC627D5F1DA3243 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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). --=20 Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org --------------enigDF29E439ECC627D5F1DA3243 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAku/iRQACgkQ84KuGfSFAYD20ACeN9PKCDvhN2LgqcNpBGayuge0 EdEAn1kHAKUb5Xho0/9Tj2MHkReM0puZ =UepP -----END PGP SIGNATURE----- --------------enigDF29E439ECC627D5F1DA3243--