This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore head

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 7 Apr 2011 09:52:22 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Thu, 07 Apr 2011 01:53:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D9D9263020000780003A58E@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <3aecf852f357e9217144.1302103165@xxxxxxxxxxxxxxxxxxxxx> <19868.35898.53337.358242@xxxxxxxxxxxxxxxxxxxxxxxx> <4D9D9263020000780003A58E@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-04-07 at 09:30 +0100, Jan Beulich wrote:
> >>> On 06.04.11 at 17:52, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH] libxl: do not expose 
> > libxenctrl/libxenstore headers via libxl.h"):
> >> libxl: do not expose libxenctrl/libxenstore headers via libxl.h
> >> 
> >> This completely removes libxenstore from libxl users' view.
> >> 
> >> xl still needs libxenctrl directly due to the direct use of the
> >> xentoollog functionality but it is not exposed to the indirect linkage
> >> anymore.
> > 
> > Applied.
> > 
> > Shame about the lack of API compatibility, but really the old was too
> > awful.
> Shouldn't API incompatible changes lead to immediate bumping of
> the major version of the affected shared library?

I guess so. I must admit I thought we had the policy (however
ill-advised) of tying the SONAME to the Xen version, but I see that in
the case of libxenlight we do actually have an independent SONAME.

I wasn't sure which digit of the major number I was supposed to
increment so I went with the first... Perhaps a comment immediately
prior to the variable could describe the requirements?


libxl: bump SONAME after binary incompatible change.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

diff -r 21db129fe3d8 tools/libxl/Makefile
--- a/tools/libxl/Makefile      Thu Apr 07 09:35:15 2011 +0100
+++ b/tools/libxl/Makefile      Thu Apr 07 09:46:25 2011 +0100
@@ -5,7 +5,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
-MAJOR = 1.0
+MAJOR = 2.0
 MINOR = 0

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>