Garrett D'Amore wrote:
> If KDE has a way to shield applications underneath from such a binary
> breakage, then its a different story altogether.
It easily can do that. The key is to realize that "binary compatibility"
is not a forever thing, or a global thing, but lasts only until a Major
release of a consolidation is released as part of a larger product.
If KDE were to make this C++ library a standard part of its consolidation,
then KDE could promise to never change it incompatibly unless KDE itself
were to produce a Major release of KDE.
In the same way as we would not expect or require absolute binary
compatibility between KDE.old clients and KDE.major.new servers,
we would not require absolute binary compatibility from its C++
library.
> To put this in comparison, imagine if almost all of the standard C
> functions were simply *macros* rather than functions, and the macros
> made references to volatile innards of the C library.
If we did this, our promise would have to be "binary compatibility
guarenteed only until we changed things incompatibly", at which point
we would have to up the major version number of ON (and thus SunOS
and Solaris because of the transitive law of maximal inconvenience...)
For stuff like libc and core ON, absolute compatibility over eons is
a no brainer; elsewhere it may easily have less (or even no) value.
All this proves is that binary compatibility isn't a global constant.
-John
