[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:18:14
Message-ID: AANLkTimzhxbNs7BpKiYYmEocW-+FJQ=7_-Fhp-KKsytu () mail ! gmail ! com
[Download RAW message or body]

On Sun, Oct 3, 2010 at 10:32 PM, Alexander Neundorf <neundorf@kde.org> wrote:
> On Friday 01 October 2010, Andreas Pakulat wrote:
>> On 01.10.10 15:32:41, Lubos Lunak wrote:
>> > - WTH does e.g. ksysguard install libraries .so and .h files for
>> > something that looks a lot like its internal libraries?
>>
>> In case this is about libprocess/libprocessui they are not internal.
>> They're useful for apps that want to present a widget with a list of
>> processes in a nice way. KDevelop uses that to select a process to
>> attach gdb to it. They were supposed to move to kdelibs at some point,
>> but that didn't happen yet unfortunately.
>>
>> Having said that, I generally agree that there's too little information
>> and awareness (among developers) about BC. In particular there's no
>> place that clearly says for each module which libs should keep BC and
>> which don't. Its apparently also pretty unknown to developers that when
>> BC is broken the soname needs to be changed. So part of the problem is
>> more of informational than a technical one (maybe even social) to make
>> developers aware of their responsibility when installing shared libs.
>
> What about source compatibility ?
>
> At least for kdelibs we try to guarantee source compatiblity of the cmake
> files.
>
> Alex
>

I think source compatibility is easier to maintain because it is more
obvious when you break it and people generally understand it better
than binary compatibility. I don't think we have a problem keeping
source compatibility atm, do we?
[prev in list] [next in list] [prev in thread] [next in thread]