> If one restricts oneself to use only libraries part of KDE Frameworks, but not > from the "Extragear" domain, one should reconsider it, this does not make much > sense as long one also uses non-KDE-party libraries (which also do not follow > KF rules).
Plasma effectively has such a rule. Treating this as a more meta discussion about libs, sure, with KDE rules in extragear you can change ABI/API but the consequences still mean in reality you can't. Release an incompatible lib, things explode until recompiled. If we use a lib in plasma and in an application and then change the lib API we always have a window where either applications latest release or plasma latest release won't compile against the released lib. Even if you bump the .so version the headers aren't co-installable. Being in this situation where we break ourselves means every packager would murder you on sight. Due to this release problem Plasma has previously made any use of extragear (or unstable 3rd party) #ifdef'd and always not in core functionality. >But I recommend to do as others and not bind to current first ABI for some time to come Note this is all somewhat moot for this specific case. There is only a QML import. It can change ABI all it wants. Changing API is also doable as long as QML import bumps and the old version still works.