[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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.