Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Samstag, 9. November 2019, 14:16:08 CET schrieb David Edmundson:
> > 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.

I am confused this is assuming one releases an incompatible library not using 
respective versioning schemes and not allowing parallel install?
But people do that properly, no?
 
> 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

Why the "even"? One should. That's what the purpose of the so version is.

> the headers aren't
> co-installable.

Some projects do proper version namespaces also for include path on changed 
ABI. If projects do not, they should start to do IMHO.
Even without, normally developers only work against one version of the 
library, so just having one variant of headers installed works good enough.

> 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.

Given Plasma requires recent versions of KF on .0 releases, the same can be 
done also for newer versions of non-KF libraries, where one then switches to 
the new API series. No need for #ifdef.

> >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.

That is no different to normal compiled library symbols, no?
One also cannot break "ABI" (not sure what the respective name would be in 
dynamic languages), i.e. change names of symbols or their types at QML layer.

Think QQC 1 and QQC 2.

Of course this comes at cost. But personally I am willing to pay that price 
over having to stick with API which proved to be not good enough and thus 
makes my own code worse.
Thus my 2 cent recommendation to stay flexible for now :) But everyone has 
different priorities, just wanted to make you consider this.

Cheers
Friedrich