Is there a methodology to avoid backwards incompatibilty that is sometimes enforced upon us?

Question

Sometimes, 3rd party libraries cause havoc when they change their interface. In some languages, it even happens on the language level.

Is it possible to write our code in a way that will prevent it?

For instance, I can think of one way - writing your own wrapper functions.
In that way, the changes will be localized to one function. But then again, it creates a large overhead.

Do you have any ideas?

Answer 1

Apple suggests to its developers the idea that your code can check for versions; then you can update your code as needed when a version changes. Here's a link to their more thorough discussion:

Mac OS X Developer Release Note

Basically, they provide markers that can be used in header files to indicate the max version in which a component is meant to be used or is known to work.

Answer 2

Basically, you include some sort of version mechanism (generally with more granularity than just low/high version limits), and you try to keep interfaces separate and "orthogonal". But a lot depends on which side of the interface you're on. On the "consumer" side you can only do so much.

IBM System/38 and it's descendents managed to maintain compatibility such that programs compiled on the first release could still be run, without recompiling, 30 years later (and through two revisions of the machine instruction set, the second quite drastic). But that is an unusual case of pretty good (though not perfect) original design, combined with fairly strong motivation (large banks that spend a lot of $$ on the systems) to maintain compatibility.

At the personal computer level many system designers don't really care, since incompatibility sells more software upgrades, which in turn sells more hardware.