[libvirt] Add GVirConfigDomainDiskDriver

Guido Günther agx at sigxcpu.org
Wed Jan 8 07:36:06 UTC 2014


On Tue, Jan 07, 2014 at 11:54:57PM +0100, Christophe Fergeau wrote:
> On Tue, Jan 07, 2014 at 11:21:22PM +0100, Guido Günther wrote:
> > On Mon, Jan 06, 2014 at 10:59:31AM +0100, Christophe Fergeau wrote:
> > > Hey,
> > > 
> > > On Mon, Jan 06, 2014 at 10:40:49AM +0100, Michal Privoznik wrote:
> > > > It's been a while since the last time I've written something for
> > > > libivrt-glib. So just my two cents: I'd say go with new class esp. if
> > > > there's a chance for attributes to expand. Although, we still have to
> > > > maintain the old APIs to set some driver attributes directly - I guess
> > > > there's no way of deprecating/dropping those APIs right?
> > > 
> > > They are marked with G_DEPRECATED_FOR in patch 3/4 so that the compiler
> > > warns about uses of the old methods. We still haven't (officially)
> > > committed to API/ABI stability for libvirt-glib, so if we were to do such
> > > breakage at some point, we could remove them at the same time. For now, I
> > > agree it's easier to just keep the old API.
> > 
> > In this case it'd be nice to force users of the lib to define
> > 
> > #define LIBVIRT_GLIB_API_SUBJECT_TO_CHANGE
> > 
> > and fail compilation otherwise so we at least state publically that the
> > API might change. We're shipping this lib in distros so not doing s.th.
> > like this might hit users with surprise.
> > 
> > I was under the impression that the introduction of symbol versioning
> > was done to keep the ABI stable? If not can we at least bump the soname
> > when dropping symbols?
> 
> libvirt-glib README is still stating:
> "NB: at this time, libvirt-glib is *NOT* considered API/ABI stable. Future
> releases may still include API/ABI incompatible changes."
> If (and I'm saying if, not when) we were to do such API/ABI breakage, this
> would go with a soname bump.

I didn't spot this in the README but with a soname bump everything is
fine. Thanks for the update! I'll make this more prominent in Debian's
package description as well.
Cheers,
 -- Guido




More information about the libvir-list mailing list