[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore headers via libxl.h
>>> 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
> 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