I'd just like to point out as a KDE developer that we don't go changing our APIs all willy-nilly.
Every major release I can remember (since KDE 2.0) has kept binary compatibility for the libraries (see http://techbase.kde.org/Policies/Binary_Compatibility_Issues...). There have been exceptions for Plasma libraries, but those were announced beforehand.
Many current KDE libraries are evolutions of technology going back to KDE 2 (for better or worse).
Perhaps the biggest change over the whole lifetime has been the shell (going from kdesktop+kicker in KDE 2+3 to Plasma in KDE 4) and going from aRts in KDE 2+3 to Phonon in KDE 4.
Btw, we were highly encouraged to adopt the popular multimedia framework at the time (gstreamer 0.10) instead of writing Phonon. gstreamer will soon be releasing an incompatible 1.0, while in the interim Phonon gained native support for the sound server that become highly popular in the meantime, PulseAudio.
KDE has been doing its part to insulate developers as much as possible from mandatory API changes. It's not as good as the kernel or Microsoft has been able to do, but it's certainly not as bad as GNOME IMHO.
I can say this as an app maintainer too. Going onto the KDE 4.10 development cycle, JuK still has code that uses the "kde3support" library. :(
I'd just like to point out as a KDE user, I had much less problems with the graphics drivers that with Gnome 2.x or Gnome 3.
The thing that make to change from Gnome 2.x to KDE 4 was that Gnome was running at slug speed with VESA driver (ATI drivers not working well in a barebone that was making for the TV), when KDE/KWin was running pretty smooth. Plus in this last years and tested that when the crap ATI drivers introduce some instability to the GUI, KDE at least self-recover alone very quickly and I don't get unusable GUI, like I saw with Gnome shell + ATI privative drivers.
Finally, I love how I can customize my desktop to my needs... It's like the old times when Enlightenment was the cool and beautiful wm, but easy to change anything.
KDE 4 isn't perfect, but I think that it's much better that the crap that Gnome is actually.
I've stopped following KDE like 5 years ago, but I remember constant changes to the multimedia APIs. Also each new QT version (2->3->4, now 5) brings incompatibilities, no?
The multimedia API changed from KDE 2 and 3's aRts to KDE 4's Phonon. The API is still Phonon, and this will be true in KDE 5 as well.
There were other application-specific APIs that were used for things that were beyond the capability of aRts and Phonon (e.g. Juk could use gstreamer directly in KDE 3) but the KDE APIs themselves were pretty stable.
It's true that a Qt change in binary incompatible and involves at least some source porting effort, but honestly those have been fairly infrequent, and only one of those transitions (3->4) involved more than minor source changes. Qt 4 was released at the end of 2005 (around the time of Linux 2.6.15) and is still the "current" version, though the Qt 5 release is around the corner.
In just the KDE 3 timeframe to now, on the other hand, there has been gstreamer 0.6, 0.8, 0.10, soon 1.0, PulseAudio, ConsoleKit, HAL, HAL's replacement (DeviceKit), DeviceKit's replacement (udev and friends, upower, udisks, etc.), PolicyKit, PolicyKit's replacement ("polkit"), NetworkManager 0.8, NetworkManager 0.9.
Needless to say, trying to keep in sync with all of that has not been fun. :-/
Every major release I can remember (since KDE 2.0) has kept binary compatibility for the libraries (see http://techbase.kde.org/Policies/Binary_Compatibility_Issues...). There have been exceptions for Plasma libraries, but those were announced beforehand.
Many current KDE libraries are evolutions of technology going back to KDE 2 (for better or worse).
Perhaps the biggest change over the whole lifetime has been the shell (going from kdesktop+kicker in KDE 2+3 to Plasma in KDE 4) and going from aRts in KDE 2+3 to Phonon in KDE 4.
Btw, we were highly encouraged to adopt the popular multimedia framework at the time (gstreamer 0.10) instead of writing Phonon. gstreamer will soon be releasing an incompatible 1.0, while in the interim Phonon gained native support for the sound server that become highly popular in the meantime, PulseAudio.
KDE has been doing its part to insulate developers as much as possible from mandatory API changes. It's not as good as the kernel or Microsoft has been able to do, but it's certainly not as bad as GNOME IMHO.
I can say this as an app maintainer too. Going onto the KDE 4.10 development cycle, JuK still has code that uses the "kde3support" library. :(