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

["Jan Beulich" <JBeulich@novell.com>]

>>> On 07.04.11 at 10:52, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-04-07 at 09:30 +0100, Jan Beulich wrote:
>> >>> On 06.04.11 at 17:52, Ian Jackson <Ian.Jackson@eu.citrix.com> 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?

Indeed, since changing either is fine from a compatibility
perspective here. I rather wonder why (other than most other
shared libraries) we store two numbers into SONAME in the
binary.

Jan

> Anyway:
> 
> libxl: bump SONAME after binary incompatible change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> 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