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