|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-devel
Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore head 
| >>> On 07.04.11 at 10:52, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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?
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@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
 | 
 
| <Prev in Thread] | Current Thread | [Next in Thread> |  | 
[Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h, Ian Campbell
Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore	headers via libxl.h, Ian Jackson
Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore headers via libxl.h, Jan Beulich
Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore headers via libxl.h, Ian Campbell
Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore headers via libxl.h,
Jan Beulich <=
Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore	headers via libxl.h, Ian Jackson
Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore	headers via libxl.h, Stefano Stabellini
Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore	headers via libxl.h, Ian Jackson
Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore	headers via libxl.h, Jim Fehlig
libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl: do	not expose libxenctrl/libxenstore headers via libxl.h), Ian Campbell
Re: libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl:	do	not expose libxenctrl/libxenstore headers via libxl.h), Christoph Egger
Re: libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl:	do	not expose libxenctrl/libxenstore headers via libxl.h), Ian Campbell
Re: libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl:	do	not expose libxenctrl/libxenstore headers via libxl.h), Ian Jackson
libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl: do	not expose libxenctrl/libxenstore headers via libxl.h), Ian Jackson
Re: libxl API changes for 4.2 (Was: Re: [Xen-devel] [PATCH] libxl:	do not expose libxenctrl/libxenstore headers via libxl.h), Jim Fehlig
 |  |  | 
  
    |  |  |