Plan to transition to KDE Frameworks

[David Faure]

Hi everyone,

It's getting rather late here, so I'll skip introductions and get right to the point :-)

Until 4.7 is branched, we keep fixing bugs in kdelibs 4, and work on trying to 
get the things into Qt 5 that we need -- about 20 KDE-related people will be
going to the Qt Contributor Summit, that should help.

Once the 4.7 branch is created, the plan is to do the following:

- application developers can work in master as usual, no change there.

- we create a new branch in kdelibs (say, "frameworks") for the work on splitting up kdelibs and reworking dependencies.
  Initially, this work is based on Qt 4. We don't need Qt 5 to reorganize our own code.

- kdelibs in master is frozen. No work going on there.
   At most, "merging" the fixes from 4.7 branch.
   (No git bikeshedding please, when I say merging it can be either merge or cherry-pick, I don't care)
  The idea here is: people who are used to "get everything from master" can keep doing that, without hitting the lib-splitting breakage.
  But at the same time, we don't really want to apply bugfixes to three branches (4.7, master, frameworks).
  At least I'm too lazy for that, I think two branches is plenty already. :-)
  Dividing our efforts is never a good idea. So the kdelibs-master branch would be basically dead
  (no work going on there, no release from that code), until the frameworks branch is merged into it.
  
  To ease testing, kde-runtime will probably be branched at the same time, in order to have matching
  libs and runtime bits (and possibly to move together stuff that belongs together).

  Once the code is fully reorganized, we will move each library into a separate git repository.
  (technical git note: Olivier Goffart showed us a very cool trick with git graft which allows one to chain
   the history of a git module to another one, thereby preserving history when moving code between git modules).
  We are working on solutions to make it easier to manage split-up git repositories more easily, there is
  Alex Neundorf's current work on a cmake-based solution, and kdesrc-build's module-set feature.

- at some point we switch to Qt 5, in order to test it and to be able to use the features that we might need
  from Qt. On that note: if you look at the dependencies plan PDF, most Qt Addons in Tier 1 are something
  that "should ideally be in Qt", or at least something that any Qt developer might want to use.
  So if we do get things into Qt, this diagram can change a bit with things moving down (which is good).
  The point is that the diagram currently assumes the worst, i.e. that we can't get anything into Qt; we'll see
  how that goes.

- at that point, we create a frameworks branch for kdesupport modules in order to port them to Qt 5.

- later on, we create a frameworks branch in kdepimlibs in order to split it and port it to Qt 5.

This plan is only about KDE Frameworks. For the KDE Applications and Workspaces, nothing is decided yet,
that is still to be discussed, for instance at Desktop Summit. There is no rush in doing that.
This migration will be different from the previous migrations because the goal is to preserve source
compatibility as much as possible. So there is no need to adapt the rest of the code while we make
changes in the KDE Frameworks. This is why the rest of the code can be branched much later.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).