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?
Xen-devel mailing list