[gst-devel] .so versioning

[Erik Walthinsen]

Currently, the CURRENT version (equiv to MAJOR) has been upped to 2 and
now 3.  I think this is inappropriate for a project of this stage.

The stated reason for incrementing CURRENT is to follow the libtool
guidelines, which state that it must be incremented any time there is a
change in interface, which typically means a change that causes binary
incompatibility.

Now, currently the gst API is still heavily in flux.  It's still very much
in alpha stage.  We break binary compatiblity on every release.  We will
be breaking binary compatibility on every release until probably 0.5.0 at
the earliest.

Now, the reason I think using a CURRENT of anything but zero at this point
is inappropriate is that it states that we have an interface.  Now, as far
as I'm concerned, an interface isn't just an ABI, it's an ABI that the
developers have agreed to settle on and 'support'.  We have not reached
that state, because we're still hashing out the interface.

This is why I believe that CURRENT should be reverted to 0 (zero).

I do *not* however, suggest that we use the package version as the lib
version.  This is broken by definition.

Now, there is another way to do this for alpha-level libraries: -release.
This trick is described in the libtool info node "Release numbers", under
"Versioning".  The idea is that for libraries that change very frequently,
the release number (aka package version number) becomes part of the
soname, i.e. libgst-0.3.2.so.  This is transparent to applications because
of libtool, but it does not allow ld.so to search for an older or newer
library.

This is precisely what we want IMO, because among other things, until we
settle on a first ABI we will support, we won't be able to retain either
backwards of forwards compatibility anyway.

As for packaging, there are two issues to deal with.  The first is that
fact that there are packages out there that have soversions of 1:0:0 and
higher.  This is mostly a problem for Debian, as the package name itself
contains the CURRENT soversion.  This means there are packages by the name
of libgst1 and libgst2 that are old.  The first assumption I'm going to
make, that taaz pointed out, is that we aren't in Debian sources.list yet,
so the number of peopel who'll have libgst2 still installed by the time
the real libgst2 comes out (year[s] from now) will be approaching zero.
The second part of the solution is a simple strategy of Conflicts: and
Requires: to ensure that nothing gets mangled.  Since new packages will
depend on libgst0, and dpkg doesn't have smarts to "realize" that libgst2
is newer than libgst0 (which would be false in either case), this will
solve itself.

The second issue is what to do with application packages.  Currently,
there are none that aren't directly under our control, so it isn't a
problem.  Between now and when we stabilize on some kind of supportable
ABI, we may have applications that will be packaged (and used) separately.
However, I don't think it's a significant problem to simply assume that
these packages will have a Requires: libgst0-0.3.2, rather than just
libgst0.  We can then use libtool's -release to make sure that the
libraries are locked into that package release cycle, and everything
works.

So, the open question as far as I'm concerned is: is there a useful way to
use REVISION and AGE while CURRENT remains 0, or should we simply use
-release?  If we use -release, do we drop the soversion on libgst
entirely, or leave it there at 0:0:0 (we have a choice, and it doesn't
affect linking afaict)?

Longer-term, we need to determine how soon we want to try to stabilize and
settle on an ABI.  We need to make a list of what general features we
have, which ones we don't, and which of those we need to deal with before
we settle on an ABI.  The sooner the better, and we can actually increment
the soversion CURRENT to 1 and start expecting external applications to
link against us.  I think the GNOME2 release is going to have a reasonable
amount of impact on that timing.

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_