Two weeks ago KDE Frameworks 5 has been branched off as planned. Meanwhile we have also gotten the fallout of that on the CI under control, and so KDE Frameworks 6 development is entering its next phase.
All KDE Frameworks repositories (including the deprecated ones) have a
kf5 branch now, all
future KF5 releases will be made from that, the
master branch will become KF6.
This means you need to pay special attention to submitting changes to the right branch, and/or
backporting relevant changes from
kf5 when applicable. If you landed changes
in the past two weeks you might want to double-check they ended up in the
kf5 branch as well.
Also, keep in mind that
master no longer has a Qt 5 CI, so you cannot rely on your MRs
having been checked for that already when backporting.
Despite all preparations and planning the branching caused disruptions on the CI, which by now have been cleared up and things are operating normally again.
Frameworks now existing in two major versions has implications for consumers on the CI.
Currently those specify dependencies in their
.kde-ci.yml file for Frameworks either as
@stable. Those continue to be fed from the
kf5 branch, ie. for existing Qt 5 builds nothing
For consumers that already have Qt 6 builds based on Qt 6 builds of KF5, we will also continue to have such Qt 6
builds of KF5 for a transitional period. Nothing changes in that case either yet. This is also
the reason why (somewhat counter-intuitively) the
kf5 branch still has a Qt 6 CI.
For consumers wishing to use the “real” KF6 eventually, the selected branch in their
needs to be changed to
@latest-kf6. Even for extremely early adopters that is not advisable just yet though,
I would suggest to wait until at least the library target name changes are done (see below).
For users of
kdesrc-build the transition to the right Frameworks branch should have already happened
automatically. If your local setup is still using
master rather than
kf5 branches check that your
configuration has the right branch group (
Sorting out the fallout of branching also took longer than expected as the update to Qt 5.15.8 happened at the same time. That unexpectedly caused some breakage on its own, especially Android was hit hard.
For Android we needed a newer SDK version and the Gradle version used for building AARs and APKs has been updated. That requires changes to basically all our Android apps to be compatible. This isn’t doable in a backward compatible way unfortunately, ie. Qt 5.15.8 becomes the minimum required Qt version for Android builds. On the up side, the same changes are necessary for Qt 6 as well anyway, so it’s at least moving us in the right direction.
To be fair, this isn’t really Qt’s fault, those changes are necessary to support newer Android versions, and Google requires that for APKs in the app store.
Next steps in KF6 development
With tooling and infrastructure back on track and the branches set up, we can now do changes that were not possible so far as they would break API or ABI compatibility.
In particular, we are looking at getting the following changes done next:
- Changing library target names to start with the “KF6” prefix. This should also expose remaining issues for full co-installability alongside KF5.
- Port QML code to work with Qt 6, in particular changes that were not possible in a backward-compatible way.
- Remove blocks of code that are deactivated by deprecation macros.
There’s much more to do than that of course, components to move around and a ton of KF6 TODOs in the code that need to be executed. The above changes have a very wide-spread impact though, so getting them out of the way quickly should ease subsequent work.
How you can help
All of the above is the result of a big team effort, and you can be part of that!
To participate, here are the most important coordination and communication channels:
- The KF6 workboard has the overview of Frameworks tasks and their status, and same for the Plasma 6 workboard.
- There’s a bi-weekly call on meet.kde.org, topics are prepared here. The next one will be on Tuesday 31st January at 17:00 CET.
- For general communication there’s the kde-frameworks-devel mailing list
#kde-develchannel on Matrix.
There’s another way to help as well, KDE’s fundraiser. The infrastructure we do all this work on doesn’t come for free after all.