RFC: Switching to min Qt version 5.14 for KF on December 14th

Friedrich W. H. Kossebau kossebau at kde.org
Sat Dec 12 22:28:20 GMT 2020


Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure:
> Just a data point on this discussion. Every time we raise the min Qt
> version, we make life easier for KDE developers, and harder for others who
> might be thinking of integrating a framework into their project.
> 
> Just today I tried using a KF5 library to extend a single plugin in an
> existing webserver (which I don't control, and which is mostly written in
> python) [1]. That server is entirely set up with a docker environment on top
> of... debian buster, which has Qt 5.11.3.
> Fail.
> I'm going to have to apply a patch to the KF5 library as part of the
> Dockerfile, to port it back to Qt 5.11. No way I can convince them to change
> the base distribution, all I'll get as a reply is to port away from QtCore.

The other option is to use not just the latest KF version, but some older one 
which gets along with what is available. Like KF 5.65, which seems the last 
one that had Qt 5.11 as min dep. Or simply the KF which is available for 
Buster (which seem 5.54?).

If that project is fine using old (now unmaintained by upstream) versions of 
other software, it should also be fine with using old versions of KF IMHO. Or 
did you need to use some feature only available in latest KF, with no option 
to work around and do some substitute? 

I am not sure that trying to be better than the rest of the stack pays back, 
Even more given the limited human resources we have. Just see how slowly the 
KF6 board moves forward.

So I think the very data point presented here is an exotic one. And rather 
recommends to do some bugfix-only branches at points in time when minimum 
dependency is raised, along versions which bigger LTS distributions rely on 
and trying to get downstream to help with maintaining those branches.

Cheers
Friedrich




More information about the Kde-frameworks-devel mailing list