KDE Frameworks has been branched
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.
Branching
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 master
to 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.
CI
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 @latest
or @stable
. Those continue to be fed from the kf5
branch, ie. for existing Qt 5 builds nothing
changes.
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 .kde-ci.yml
file
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).
kdesrc-build
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 (kf5-qt5
) set.
Qt 5.15.8
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
and the
#kde-devel
channel 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.