Re: API break / so versioning

[Dan Williams <dcbw redhat com>]

On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote:
> Hi,
> 
> in Debian we have a nice facility which allows to track the exported 
> symbols of a shared library. Attached are the symbols files of 
> libnm-util and libnm-glib for current NM 0.6.6 and NM 0.7.0~svn3712.
> 
> What you can easily notice (by running a diff), ist that not only a lot 
> of symbols were added, but also quite a few were removed, which could 
> result in application crashes. In case of an API break, you usually bump 
> the SOVERSION, which leads to the more general question, if NM shouldn't 
> start using proper soversioning [1].

Yes, it probably should.  One thing that we've tried to do is keep the
old libnm_glib symbols around though, which is why we kept the
libnm_glib name instead or renaming it to libnm-glib instead.  So that
at least apps that used the old basic 0.6 API bits would still work.

If we're willing to ditch that assumption, then I'm all for removing
that code and bumping the soname.

> I also wondered, if the separate library libnm_glib_vpn.so.0 is really 
> necessary or should be folded into libnm_glib.so.0.

This is used by the VPN services and isn't really part of the same bits
that should be used by clients of NM.  I tend to think we should keep
them separate, since if you're writing a client like nm-applet you
shouldn't care about anything that's in libnm_glib_vpn.  Maybe Tambet
has more thoughts?

> And last but not least, skimming through libnm-glib0-0.7.0.symbols, 
> there are quite a few autogenerated symbols like
> nm_marshal_VOID__OBJECT...
> Are those expected to be part of the public API?

Nope.  There's probably a lot of symbols that aren't part of the public
API.  In the end, the public API is defined by the installed .h files.
I haven't done any symbol visibility yet because that's a PITA to set up
and maintain and makes debugging harder, but it's likely something we
should be doing in the near future.

Dan