KDE Frameworks 5, the next major evolution of KDE's library foundations, has made a series of significant steps forward in the last six weeks. Some of these steps have been more publicly visible than others, which is a bit of a shame because they are all quite exciting.
Firstly, the monolithic kdelibs and kde-runtime modules have been successfully modularized into individual git repositories. You can see the mammoth list of repositories over on projects.kde.org. This is a significant milestone that required a lot of work on the part of numerous people working for the last few years to disentangle the individual bits of KDE's libraries into neatly organized, topically focused bundles. Now people writing Qt and KDE applications can cherry pick precisely what they need and carry only those dependencies, while making contributing to these individual libraries easier to take on for new comers. This is good for everyone across the board ...
... with perhaps the exception of people building from source who now have to contend with dozens of repositories where before there were just two? Nope, not even for them. Another strategic decision made was to ensure that Frameworks was as easy to build before as after. The recommended way to build "the whole thang" is to use kdesrc-build, which is sweetly integrated with projects.kde.org. Full documentation including a pre-built configuration file can be found here on community.kde.org.
This all culminated in the recent technology preview release of Frameworks 5. There is still work to be done, however. The project is now making their way towards alphas and, eventually, betas with an ever shortening list of things to do, which is tracked on the Frameworks 5 Release Preparation page on community.kde.org.
It's gotten so tantalizingly close that several applications have started porting. This is good to exercise the frameworks and ensure they are in good fit as the alpha/beta cycles commence. In fact, yesterday Aleix Pol blogged that "everything is in place for you to start porting the project of your liking and start taking advantage of Qt5 and KF5".
While I believe it is useful to have some applications ported to give some application coverage of Frameworks pre-release, I do urge caution in making that leap just yet. It would be premature at this point to have a majority of KDE applications begin their porting. Here's why ...
The technology preview release was delayed by a couple months from first expectations. Early progress of Frameworks was not swift, but it has thankfully picked up considerably thanks to great efforts on the parts of many, many contributors. Even with that push, a technology preview was delayed into the new year. This is not the end of the world, but it does show that without a firm release schedule in place, something that is nearly impossible to do with a project like Frameworks 5 with volunteer contributors, it is hard to gauge precisely when a first stable release will happen. The timing of that release will also end up influencing when that release is available to a significant percentage of KDE's user base via binary packages available in mainstream distribution releases.
Additionally, for the vast majority of applications based on QWidget from Qt4, porting to Qt5 and Frameworks 5 will be quite quick and simple work with high quality results. The reason is simple: QWidget itself hasn't changed much at all, and certainly not in the API. Even building with all deprecated symbols off in Qt5 (which Frameworks doesn't yet do), it is generally a cakewalk in my experience. KDE's libraries have also had minimal change to API with some notable exceptions (e.g. libplasma, libkactivities..), but the most used libraries, covering the uses of probably well over 90% of KDE applications, have had minimal API changes and behavior is similarly consistent with the 4.x branches.
This means that a port undertaken now will likely be finished quickly but few of our users will be able to enjoy it. Instead, they'll stick with Qt4/KDE Platform 4 versions that aren't moving much, if at all. This is not a great result for them.
As we learned from the 4.0 release cycle years ago, applications porting too early can also lead to temptation to refactor applications in ways that are hard to stabilize without interim releases, leading to worse first release results than called for. We've addressed other issues from the 4.0 lessons, such as not releasing everything at the same time, so hopefully we will take advantage of the full breadth of lessons and make the 5.x releases awesome starting with the first "dot-oh" release.
When Frameworks 5 has a firm release schedule, then it makes sense to start coordinating application releases targets with that and syncing up development cycles.
This isn't to say that no applications should be ported. Applications relying on things like libplasma ought to get an early start as there is more work to be done there; this is why kde-workspace started right after the 4.11 release. Additionally, having applications to test the build system changes introduced in Frameworks 5 is critical to a smooth release of Frameworks 5 itself, so there should be a reasonable set of applications ported to cover the Frameworks 5 cmake based build infrastructure and support. We may already be there now, but it is hard to tell as it isn't being tracked from what I can tell.
We're in exciting times when KDE's libraries are fully maturing into a well organized set of discreet components for Qt5 that still work amazingly well together; in fact, while each delivers value on its own, the most value is to be gained from use together. A sort of library synergy, if you will. At the same time, Wayland and QtQuick2 are coming to our desktops, notebooks, tablets and beyond while applications will have a very easy skip from Qt4 to Qt5 thanks to the disciplined efforts of the Qt Project community. 2014 is going to be a fantastic year for releases from KDE ... which probably means we ought to start right now planning on how best to coordinate, announce and ultimately celebrate the fruits of long labor!