Keeping binary compatibility
George Kiagiadakis
kiagiadakis.george at gmail.com
Mon Oct 4 13:13:46 BST 2010
On Sun, Oct 3, 2010 at 8:55 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> On 03.10.10 13:23:17, George Kiagiadakis wrote:
>> However, this might be acceptable if BIC changes are documented for
>> each release, so that we know when different module versions can be
>> mixed and when they cannot. This will at least reduce the pain when
>> users need to mix different versions that *can* be used together. Of
>> course, the best way to achieve this would be to bump (or not bump, if
>> there is no BC break) sonames, which is immediately visible to the
>> packagers. So, I think we are back to the original proposal :)
>
> I think in most cases you'll simply get a new soname with each release
> of the KDE modules because most devs don't (want to/can) care about
> wether a particular change they're doing is bc or not. So they end up
> increasing soname shortly after trunk is unfrozen and thats not going to
> benefit you either (except that it would document that any two minor
> releases are incompatible).
Well, there are tools to check for binary compatibility. In debian we
use a symbols checker (which is not perfect though because it only
checks the exported symbols, not the members of classes and the
virtual tables) and now Lubos has presented a new abi checker tool
that seems more complete. Let's start using it.
More information about the kde-core-devel
mailing list