BinaryCompatibility is when the past comes back to haunt you.
Application programmers sometimes see it in that they need to load data from files which were written with previous versions of the program, possibly in a less-than-optimal format.
However, the big hit by
BinaryCompatibility is when your product is an
OperatingSystem or
ToolsAndLibraries, in which case an update to a library must preserve all documented (or undocumented but widely used) behavior of the previous incarnation.
Many methodologies, such as
RefactorMercilessly are strictly at odds with
BinaryCompatibility.
See also
FragileBinaryInterfaceProblem.
This isn't a problem provided you place versioning information at a well-defined place that isn't going to change
ever, such as at the start of the stream. Another very good technique is to use XML or XML-like structure so you can add and remove attributes and classes as you want. This makes the application
forwards, backwards and laterally compatible. Then, you may
RefactorMercilessly all you want.
As for library compatibility, you don't always have to maintain backwards compatibility, especially with static libraries. Just deprecate the old behavior and give clients one or two versions to upgrade. Then
mercilessly delete the deprecated features. If clients don't like the changes, they won't upgrade and their code will still work fine. --
SunirShah
Lack of
BinaryCompatibility often results from
PrematureOptimization. XML is a somewhat unoptimized data structure.
Another possible solution is to
TranslateMercilessly, as in
http://www.research.ibm.com/daisy/ . Applying this to libraries is left as an exercise to a PhD student.