From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Fehlig <jfehlig@novell.com>
Subject: Re: [PATCH] libxl: do not expose libxenctrl/libxenstore
	headers via libxl.h
Date: Tue, 12 Apr 2011 22:07:05 -0600
Message-ID: <4DA52169.5080502@novell.com>
References: <3aecf852f357e9217144.1302103165@localhost.localdomain>	<19868.35898.53337.358242@mariner.uk.xensource.com>	<4D9D9263020000780003A58E@vpn.id2.novell.com>	<1302166342.27835.22.camel@zakaz.uk.xensource.com>	<19869.35524.73748.363114@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1104071122140.3290@kaball-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <alpine.DEB.2.00.1104071122140.3290@kaball-desktop>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@novell.com>
List-Id: xen-devel@lists.xenproject.org

Stefano Stabellini wrote:
> On Thu, 7 Apr 2011, Ian Jackson wrote:
>   
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: do not expose	libxenctrl/libxenstore headers via libxl.h"):
>>     
>>> 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.
>>>       
>> In general I think it's fair enough to bump the soname online once in
>> each release cycle.  But now is as good as any.
>>
>>     
>>> 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?
>>>       
>> I would suggest 1.1.  I would normally increment the 2nd number of any
>> shared library unless it was a complete rewrite or something.
>>     
>
> I agree with you on the general principle but I suspect it is going to
> be almost a rewrite at the end of this development cycle :-/
>   

:-( For clients' sake, I hope the API stabilizes in 4.2 timeframe, and
no backports to 4.1 break the API in that branch.  IIRC, there have been
other API-incompatible libxl changes since 4.1.  Seems best for clients
to target new releases (4.1, 4.2, ...) and expect branch releases
(4.1.1, 4.1.2, ...) to have a stable API?

Regards,
Jim