|Subject:||The Future of our Frameworks|
|From:||Sebastian Kügler (seb...@kde.org)|
|Date:||Jun 6, 2011 10:22:18 am|
You've probably been aware that a rather sizable group of KDE developers and stakeholders in our development platform is meeting in Randa, Switzerland to discuss the future of our development frameworks, with the big topic being "modularization of kdelibs". We've had a number of great discussions here about various technical and process-related topics. We are still in the process of making the results digestable, transforming our notes into something that is understandable for those that haven't been able to participate in these -- very productive -- sessions in person.
Let me already give you some information on the bigger picture we came up with here, as you are all probably very curious about that. The overall theme was the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and kdesupport. With Qt5 -- a change in binary interface -- having been announced, it is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt5 will do for us anyway.
What is the scope?
Instead of Platform, we want to consistently use the term "Frameworks", this includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime, kdepim-runtime and kdesupport. We explicitely are not talking about our apps and workspaces, but read on.
What do we want to achieve, and why?
We want to make it possible to use our frameworks in Qt projects without significant additional dependencies. This means:
* We reach out to the Qt development community in a more focused way * We make it easier to use our frameworks * We lower the barrier for contributions * We make our frameworks more suitable for mobile and device-spectrum use cases * We make it possible to select a specific set of features developers would like to use * We improve our QA processes, leading to better quality apps and frameworks
We want this to happen with ... * ... no disruption for our users * ... little to no source incompatibilities * ... most apps not needing any significant changes * ... changes, if at all necessary being kept to a minimum
What does it mean for users?
* No disruption * Most probably invisible * Short term: Iit becomes easier to run kDE apps outside of the Plasma workspaces, including other operating systems * Longer term: We will probably see more apps using KDE technology
What does it mean for developers?
* We will maintain source compabitility as much as possible * The impact for existing apps will be minimal * We will provide a compabitility library as additional measure to reduce the impact of these changes
What does it mean for packagers?
* We make it possible to ship our frameworks in a more modular way * We also plan to provide "monolithic tarballs" much as we do now, depending on the needs and preferences of downstreams
Please note that this is *not* KDE5, as it doesn't refer to our community, but about our development frameworks. At this point there is also no benefit in talking about KDE 5, since that just opens the door to misinformation. This is also clearly not about our workspaces, or applications. (See http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick explanation.)
In order to prevent this thread from growing into an unmanageable load of hundreds of emails, please post specific questions as separate threads. (You can of course reply with praise to this, but anything that is likely to spark a more detailed discussion is probably better off in a separate thread.)
Thanks for your attention, and cheers from a wonderful Switzerland,
-- sebas, on behalf of the KDE Frameworks team