The Future of our Frameworks

[Sebastian Kügler]

Hi all,

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

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.