[libvirt] Add GVirConfigDomainDiskDriver

[Christophe Fergeau]

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.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140107/1f1d32fa/attachment-0001.sig>