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