Versioning of Frameworks

[Christian Mollekopf]

On Sat, May 9, 2015, at 01:27 PM, David Faure wrote:
> On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote:
> > we pretend it's all independent libraries but still they all depend on the
> > latest version of all other libs.
> 
> It's a question of the definition of "independent".
> 
> E.g. KCoreAddons and Solid are independent because you can use either one 
> without being forced to use the other. The fact that they are released 
> together doesn't change that.
> 

Indeed, the split up is in any case a valuable change from what it used
to be.

> KCoreAddons and KIO are partially independent because KIO depends on 
> KCoreAddons, but still there is a huge improvement there compared to the 
> kdelibs4 situation where such inter-library-dependencies were far too
> numerous 
> so it was basically all-or-nothing.
> 
> Having split two such libraries still helps tremendously, since one can
> use 
> KCoreAddons without using KIO. The fact that KIO-5.10 requires 
> KCoreAddons-5.10 is IMHO no different from the fact that QtGui-5.6
> requires QtCore-5.6. 

> Are you saying that Qt didn't "go all the way" or didn't "split 
> properly" because of the fact that QtGui-5.6 requires QtCore-5.6?
> (same thing with other Qt libs from other modules than qtbase, this isn't 
> limited to qtbase)
> 

I do think the same problem applies to Qt, and yes as long as they have
the same version for all libraries they are not completely independent.
It may be less of a problem for Qt though than it is for frameworks IMO.

> I still don't understand why this is fine for Qt and not for KDE
> Frameworks.
> 
Two reasons why Qt can get away with treating it as a single library
(which it IMO largely does):
* Qt libraries tend to be less volatile. I can implement most
functionality I require today
on top of Qt 4.6. That means I simply implement workarounds for what I
don't have available on an
older system, and I typically don't even consider changing something in
Qt (which is a shame
because it keeps me from improving Qt). We therefore simply avoid
updating Qt as far as possible,
because if we have to we indeed also have this giant blob to update.
* I'd consider Qt to be a lower level library. Qt mostly provides
fundamentals just like libc or the STL,
and it's therefore okay for me to just work with what I have available.
Qt does include a *lot* of stuff though,
which I think Qt would also benefit from truly splitting up libraries.

Frameworks for me is an umbrella for various libraries, and not a single
library. If it were a single library
it would be an "everything and the kitchen sink" library, which I really
don't think is something we should
be aiming for. So for me each framework is an individual library, and
should be treated as such,
because I do want to work on the respective framework instead of running
in my own circles in
wherever I use the framework.
I therefore need to be able to use the results of that work on all my
target platforms, otherwise working
on the framework is just having me implement the same thing twice.

So as a summary, it's only fine for Qt because I never ever have to
touch Qt, which is not a good thing either.

Cheers,
Christian