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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list