WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] libxl: do not expose libxenctrl/libxenstore head

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


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

<Prev in Thread] Current Thread [Next in Thread>