Re: API break / so versioning

[Dan Williams <dcbw redhat com>]

On Mon, 2008-06-02 at 09:44 +0300, Tambet Ingo wrote:
> On Fri, May 30, 2008 at 9:31 PM, Dan Williams <dcbw redhat com> wrote:
> > On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote:
> >> 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.
> 
> There's probably no point in keeping that anymore. The basic API is
> kept, but some of the basic defined variables have changed
> (NMDeviceState), so even if something might still compile, it probably
> doesn't work anymore.

I think some apps still use it (evolution maybe?), though that may be a
custom Fedora patch.  We could build the old bits into the .so.0 and all
the new bits into the .so.1 perhaps?

Dan

> > 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?
> 
> Yes, these should be separate. One (libnm-glib) is part of the client,
> the other (libnm-glib-vpn) part of the daemon.
> 
> Tambet