[Portland] Project Portland, RuDI and the Generic desktop adapter

[Wichmann, Mats D]

>> B) Or does it also cover binary compatibility problems caused by
>> changing APIs (function and struct signatures).
>
>> I always thought it was A, because B can be avoided through API
>> discipline.
>
>No, this is not the full picture. From time to time you want 
>to be able to 
>change the API in an ABI incompatible way. For KDE we 
>refrained from doing so 
>for the entire KDE 3.x line. But to KDE 4 we intentionally 
>want to break both 
>the API and ABI in order to allow us to innovate.

and that's fine, as long as the normal guidelines for doing
incompatible changes are followed - new library sonames,
or if it makes sense, symbol versioning.  Nobody expects
the ABI not to change over time, you just don't want it to
break underneath programs that have already been compiled.