Let’s talk about KDE software dependencies. Most KDE apps rely on KDE Frameworks which in turn rely on some version of Qt. The abstraction layers are plenty and the codebase is enormous. Oh well.
Still, I was thinking: “is there ANY way to reduce the complexity”?
Please correct me if I’m wrong but to the best of my knowledge most of the KDE software can be built with a wide range of underlying versions of their dependencies, which in turn makes it near impossible to thoroughly test for QA. This is true regardless of how much time/money/resources we allocate for KDE development.
Let’s take for example the upcoming release of Dolphin 25.04. Will it rely on KDE Frameworks 6.10? Or perhaps on 6.11? How about 6.9? And what about the Qt versions? Will it rely on Qt 6.8.1? How about 6.9? (and so on) It would seem then that the total size of tests needed (for QA) increases exponentially with each dependency version that we allow.
Please note that I am not even touching on the extra complexity added by the different packaging formats here. Is this sustainable? And most importantly, is it necessary?
I am not a developer (apart from the occasional Python script for my own needs), so please take what I say with a huge grain of salt (and feel free to educate me on why I’m totally wrong) but here’s my proposition:
Each version of KDE software should have only one official (& supported) chain of dependencies, such as: Qt 6.8.1 + KDE Frameworks 6.10.
The devs can vote/decide what that chain will be for each software release.
This will reduce the number of moving parts, hence:
It will (hopefully) immediately reduce bugs due to some bugs becoming “out of scope”/“not supported”.
It will probably make bug reporting easier.
Each bug fixed will have a bigger impact in the overall quality of KDE as fixing it will affect a larger number of users.
The devs become more efficient since they don’t have to play Whack-A-Mole with bugs. This approach respects their valuable time.
And if distros want to go out of their way to build with a non-recommended chain of dependencies instead, then they should have to deal with all the resultant bug reports. KDE bugzilla should address only bugs that relate to the approved KDE builds with the supported chain of dependencies.
Would this proposition make our devs’ lives easier? If so, perhaps we should give it a try.
Well, I’m not much of a developer either, so the following is how I see it to best of my knowledge.
I don’t think this will have much in the way of help for KDE Software, since they already do specify a minimum required Qt version ( and other libraries ) and API doesn’t change much among minor versions. They already do close bug reports for older library versions if they are fixed in newer versions, AFAIK. If the software needs a specific improvement in a specific version. they just update the minimum required version to it. After all, if there’s a bug in a newer version of the libraries, they’d have to fix it sooner or later.
And I can see this making hell for distro developers, since now the shared libraries for the entire system are locked down to the versions used by KDE software. So if another software needs a newer lib version, they would have to statically link either the dependencies of KDE software or of the other application. This could mean a heavy increase of storage usage, since every such software will have the libraries statically linked. ( And stuff like Qt can be very large )
As far as I am aware, these abstraction layers have very little to do with interfacing with different library versions and more to do with abstracting the library abstractions down to even easier to use ones.
All though most of this might not be true for stuff closer to the hardware like KWin.
You’re basically proposing that KDE software require an LTS software stack underneath it. The problem is that many layers of that stack do not follow an LTS model. We could do this for our own parts of the stack (i.e. KDE Frameworks), but we can’t even do that for Qt since the LTS versions are commercial-only these days. And all other non-KDE and non-Qt parts of the stack as a rule have no LTS releases at all.
The lack of LTS releases of underlying software is reflected in the relative lack of LTS style distros. Even for those who do ship explicit LTS style releases (Ubuntu, openSUSE Leap, Debian), it doesn’t work as well as you want it to because nobody actually wants to maintain a distro-enforced LTS software stack without being paid lots of money. As a result, bug fixes get backported much less frequently than you would hope for, leaving you stuck with old bugs for years.
Ultimately my conclusion is that the world around us doesn’t really support the proposal. Even if it did and we moved to it, in my experience most bugs aren’t caused by library versions changing API or behavior out from under us, with limited exceptions like major Qt version bumps. Frankly, most of the bugs are either our own fault, or caused by users adopting newer hardware that hasn’t had years for the driver and software support to mature.
I would just like to elaborate on my idea for clarity’s sake because I was not advocating for the LTS model at all. Neither am I calling for backporting fixes. I know this is not part of the KDE ethos.
The way I think about it, each new software release would make the previous release deprecated and unsupported. For example:
If Dolphin 25.04 is to be built on top of Qt 6.8.1 and KDE Frameworks 6.10, this would be “supported” only up until 25.10 gets released.
Practically no bug fix will happen until Dolphin 25.10 is released.
However what I am proposing is that when Dolphin 25.10 does get released then it is based on: (let’s say)
Qt 6.9 and KDE Frameworks 6.11 ← We would accept bug reports for this chain of dependencies ONLY.
If a distro decides to build with:
Qt 6.8.1 and KDE Frameworks 6.11
or
Qt 6.9 and KDE Frameworks 6.10
We do not accept these bug reports.
If the bug filed on Dolphin 25.04 is fixed on Dolphin 25.10 (KDE approved version), then awesome!
If the bug filed on Dolphin 25.04 is not fixed on Dolphin 25.10 (non KDE sanctioned dependencies version), then it’s not our problem.
If the bug filed on Dolphin 25.04 is still present on Dolphin 25.10 (KDE approved version), then it’s still our problem and we need to work to address it in future versions.
Maybe I’m jsust overcomplicating things though.
As you said:
so I guess my proposal is trying to address a problem that’s not there at all. Good to know!
I get your idea, which is that locking the required dependency versions would increase stability.
If we did this, I think we would be cutting off our own nose to spite our face: the principal type of bug report worth ignoring because it isn’t actionable is the one from KDE software released a year ago or earlier — not recent KDE software built with a slightly different version of Qt or KDE Frameworks. Almost all of these bug reports can be actionable despite the slightly different library versions.
