[gst-devel] .so versioning

[David I. Lehn]

I'm on the other end of this disagreement so here's my reponse:

* Erik Walthinsen <omega at temple-baptist.com> [20020201 04:57]:
> 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.
> 

I started this CURRENT upgrading two releases ago.  (no one has objected
until now afaik).  The reason was to deal with debian packaging issues
so that people could start to write apps that depended on a particular
version of the API.  And I personally think by releasing shared libs at
all we HAVE to do this versioning.  Sure I realized CURRENT would change
every release for a while but so what?  I figured it was better to just
let the CURRENT increase and allow people to do proper Depends: to not
break packages on upgrades.

I'm taking a totally technical view of the issue.  I think it's
irrelevent if the API is in flux or stable.  I think we should follow
those libtool versioning guidelines depending on how we change the API.
Once we release code it's hard to just assume that no one is using it or
wants to upgrade smoothly.

I really don't see the problem in doing it the libtool way.  One
argument seems to be we are commiting to supporting an API.  I disagree.
I don't see any such implications in these numbers, they are just there
for linking and upgrade path support.

Fine by me if our 'stable' API has CURRENT of 25.  Why does this matter?
At some point we'll stop changing the API and REVESION and AGE will
start being used more often.

Heck, I think I'd have MORE confidence seeing a lib that has gone
through a bunch of revisions reflected in the lib version.  And
realistically, based on the frequency of our releases, we won't go
through more than a handful of CURRENT++.

I'm not sure on how to handle other schemes for debian packages.  I'll
have to seek some help on it.  Dealing with reverting to non-versioned
libs is doable.  But I just have no idea how to handle future upgrades
without breaking everything that depends on the libs.

My vote is to use the libtool guidelines.  Assume we have a thousand
apps and millions of users.  On each release, no matter how small, we
want to support an easy upgrade path.  I think this is easily done
through the life of the project.  We'll end up with higher than
"average" lib versions which, imho, just means we have mature code.

If it's decided not to do this can someone please explain to me how to
deal with the Debian lib upgrade issues.  Thanks.

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA