[NTLUG:Discuss] Upgrade breaks things

[Steve Baker]

Bobby Sanders wrote:
> 
> I had always assumed that libraries _were_ backwards compatible,
> i.e. if it works with lib.x.0.1 it should work with lib.x.0.2.  If
> /lib/modules/2.4.8-34.1mdk/modules.dep is backward compatible with
> /lib/modules/2.4.8-26mdk/modules.dep, perhaps a soft link would work?

In an ideal world, you'd think so.

I maintain several graphics libraries - and spend a good fraction
of my time worrying about this.  There are three problems:

  1) With dozens of contributors, it can be hard to be certain
     that they are all keeping backwards compatibility in mind
     at all times.  The way to avoid that problem is to CAREFULLY
     check every single contribution before it makes it into the
     released library...that's what Linus does with the kernel
     for example.  However, that can be a MASSIVE amount of work
     and not everyone is prepared to put in the effort needed.

  2) Sometimes a library is released with a bug in it.  Suppose
     some angle is supposed to be provided to the library in
     degrees - but due to a bug, the library forgets to convert
     it into radians before passing it to the cosine function.
     Application writers notice this problem, but instead of
     reporting it as a bug and patiently waiting for it to be
     fixed - and a new copy of the library being released - before
     releasing their application, they go ahead and kludge a fix
     by passing the angle in radians.  Now, when the fixed library
     is released, the application won't work with it.  YUK!

  3) Some libraries require a *structure* to be passed as a parameter
     to some library call.  If at some future time, a new variable
     has to be added into that structure, it's almost impossible to
     do it without breaking reverse compatibility.  This problem
     is especially acute for C++ applications that actually make
     use of a class-based interface.

There are ways to deal with all three of these issues - but it's
really hard for a maintainer to keep track of all the ugly problems.

The way I deal with it in my libraries is to have applications
statically link to them...but that's only appropriate because
there are very few applications using them.  You couldn't have
glibc or OpenGL work like that (for example).

The other way out is not to attempt to maintain 100% compatibility,
but instead to make sure that multiple versions of the same library
can co-exist on the same computer and that applications always pick
the right version.  Linux makes an attempt at that - but it's far
from 100% sucessful.

I don't know what the answer is - but I don't expect it to get a
whole lot better anytime soon.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1 at airmail.net>   WorkMail: <sjbaker at link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net