Re: [libvirt] Add GVirConfigDomainDiskDriver

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.