Keeping binary compatibility

[Aaron J. Seigo]

On Friday, October 1, 2010, Lubos Lunak wrote:
> (http://linuxtesting.org/upstream-tracker/versions/kde-libs.html), which is
> not as green as it should be.

one of those is a commit by a plasma contributor that snuck one past us doing 
commit reviewing. it's really hard to catch every such event, and i agree with 
you that it's probably innevitable unless we have some automated testing.

thank you for getting that going. it's quite awesome.

> with e.g. kdeedu libs? I'm asking because, consider e.g. these errors from
> an attempt to uninstall kdebase/workspace package here:
> 
> libkscreensaver.so.5()(64bit) is needed by (installed)
>     kdeartwork4-screensaver-4.4.4-2.1.1.x86_64

i think the expectation there was that kdeartwork would be installed in lock-
step with kdebase. probably a hold over from the kde3 expectation of things. 

in any case, nothing in this library has changed in forever, but it also isn't 
ready to become binary compatible, mostly due to lack of dptr usage in public 
classes. that would be easy enough to fix, bump the .so #, and then commit 
that library to having BC.

> libkworkspace.so.4()(64bit) is needed by (installed)
> ktorrent-3.3.4-4.1.x86_64 libkworkspace.so.4()(64bit) is needed by
> (installed) kor-0.3-2.2s.x86_64 libsolidcontrol.so.4()(64bit) is needed by
> (installed)
>     ktorrent-3.3.4-4.1.x86_64

ktorrent shouldn't be linking to any of these.

> libsolidcontrol.so.4()(64bit) is needed by (installed)
>     kbluetooth-0.4.2-3.1.x86_64
> libsolidcontrol.so.4()(64bit) is needed by (installed)
>     NetworkManager-kde4-libs-0.9.svn1057339-4.1.x86_64

afaik libsolidcontrol is being phased out. networkmanager is also likely to be 
moving into kdebase/workspace/ at some point anyways, which will make this one 
"go away". kbluetooth is perhaps another good candidate for similar movement.

> libtaskmanager.so.4()(64bit) is needed by (installed)
>     ktorrent-3.3.4-4.1.x86_64
 
oi vey. another library they should not be linking to.

>  Looking at how KDE provides various libraries leads to a number of WTH
> questions, like:
> - WTH is the ABI stability documented, besides kdelibs?

nowhere, probably :/

> - WTH does e.g. libtaskmanager seem to have soname versioning following SC
> version, like stable kdelibs libraries do, but it's not actually stable?

because the intention was to eventually make it BC. it obviously didn't 
happen, things continue to evolve in it. we could certainly make a deadline 
for keeping BC (e.g. 4.6) and freeze it there. or we could keep going as we 
are currently (breaking BC from time to time, but not in a stable branch), and 
put NAMELINK_SKIP in there. would that be enough?

>  Therefore I propose the following:
> - private libraries do not (obviously ...?) install their .h files and do
> use NAMELINK_SKIP option in install (see e.g.
> http://websvn.kde.org/trunk/KDE/kdebase/workspace/khotkeys/libkhotkeyspriva
> te/CMakeLists.txt?r1=862343&r2=895764) 
> - ABI stability for each public
> library is documented, I would suggest a README.<library> file in sources
> and in the main doxygen page

README files tend to bitrot IME. apidox is a good place. techbase is another 
good place. a "whitelist" page showing all libraries that have BC commitments 
(with the implication that if we ship them, but they aren't on that list, 
don't expect BC) would make sense to me. it's probably the easiest place to 
find these things for 3rd parties.

> - ABI of each stable library (obviously) does not change
> - whenever ABI of an unstable library changes, its soname is increased
> (which means that each library will need in its CMakeLists.txt something
> like this
> http://websvn.kde.org/trunk/KDE/kdelibs/plasma/CMakeLists.txt?r1=879765&r2
> =879766& , handled manually, instead of generic macros)
> - the release team howto gets a new entry 'each new version is ABI tested
> before release' 

sounds great.

and again, thanks for bringing this tool to KDE :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20101001/a0babab2/attachment.sig