Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Anyway:

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
 
 XLUMAJOR = 1.0



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel