[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Keeping binary compatibility
From:       George Kiagiadakis <kiagiadakis.george () gmail ! com>
Date:       2010-10-04 12:13:46
Message-ID: AANLkTinAUK_yj3VfYpbhx7Cw==ArF71N_JFqxYE5_HdY () mail ! gmail ! com
[Download RAW message or body]

On Sun, Oct 3, 2010 at 8:55 PM, Andreas Pakulat <apaku@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.
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic