Which package will provide the common KDE library version number ?

[Alexander Neundorf]

On Friday 24 February 2012, Sune Vuorela wrote:
> On 2012-02-24, Alexander Neundorf <neundorf at kde.org> wrote:
> > * the version numbers of the projects themselves
> > * the required Qt version
> 
> This might differ across frameworks. I see no reason to artificial bump
> required version.

If this is handled properly for each library, then there is no problem. But 
this is a big "if".
A common setup will be that "core" developers are building all frameworks 
libraries.
Let's say some tier1 library, e.g. kcore needs Qt 5.1.2 and cmake 2.8.9.
Another tier1 library, let's say solid, maybe says it needs Qt 5.1.0 and cmake 
2.8.8.

But since due to kcore already Qt 5.1.2 and cmake 2.8.9 are installed and 
available, it may, no, it will happen that solid accidentially uses features 
from Qt 5.1.2 and/or cmake 2.8.9. The developer will not even notice that the 
required versions of Qt and cmake (5.1.0 and 2.8.8) are wrong.
So other developers will try to build solid and it will fail at buildtime.

I am quite sure this is what will happen if they don't share common required 
versions.
So you (as packager) will end up with packages stating wrong required 
versions.

IMO it is part of the "KDE" development model that a C++ developer not 
necessarily has to care a lot about e.g. translations, packaging, releasing 
and building, because there are specialist who do that in the team.
By not requiring common required versions, this task moves from the 
buildsystem maintainer to the C++ developer (because I will not go through 50 
libraries and check whether they use any features which don't match their 
required versions).
Do we really want that any of the let's say 20 libraries can require a newer 
version Qt and so enforce a rebuild for everybody ? or cmake ?
If they don't share an enforced common required versions, it is perfectly ok 
for them to do so.

Such a change really changes the libraries which make up kdelibs now into a 
set of *completely* separate libraries.
While this is nice and good in theory, in practice we may very well end up in 
version and dependency hell.

Are we really ready to go there ?

Maybe the few developers here on kde-frameworks are (except David), but I 
don't think this is true for everybody else.

...
> >> repositories to another solution having another script keeping another
> >> line in sync across repositories.
> >> 
> >> Either the "set(CURRENT_LIBRARY_VERSION 5.3.10)"
> >> or the
> >> find_package(KF5BuildSpecs 5.2.3).
> >> 
> >> And by chosing the latter we require everyone to do complete lock-step
> >> upgrades.
> > 
> > What  is a lock-step upgrade ?
> 
> A requirement to upgrade other packages to upgrade a different package.
> 
> Like FrameworkA and FrameworkB. One is related to fetching imap mails,
> the other   is related to paint svg images on screen.

Ok.
 
> I could imagine to want to be able to upgrade one without the other.
> Given we promise source and binary compatibilities, it should be
> perfectly possible. Except if we introduce artificial limitations like
> this one.

There are valid reasons to add these artificial limitations, see above.

Alex