KActivities split, 2nd phase

[Ivan Čukić]

I have a cunning plan. It is as cunning as a fox what used to be a
Professor of Cunning at Oxford University but has moved on and is now
working for the U.N. at the High Commission of International Cunning
Planning. </end blackadder reference>


As previously mentioned, the problem is that someone who upgrades the
framework might get a few components missing.

kactivitymanagerd is not really a problem - it can be seen as a
dependency of the framework.

The problems are kio and kcm.

Now, if kio and kcm were to be a part of kactivitymanagerd repository
(or a separate repository**) for a short while, the problematic setups
might be avoided.

1. part: release kactivitymanagerd+kio+kcm at the same time as the frameworks
  this will make it easy to upgrade to the new version - nothing will
be missing from the setup. This release schedule can be followed until
the release of Plasma 5.x (Plasma 5.6, or if we want to give the
transition period three more months, until Plasma 5.7).

2. part: when Plasma 5.x is released, start releasing
kactivitymanagerd+others synchronized with plasma instead of with
frameworks.
In Plasma 5.(x+1), move kio and kcm away from kactivitymanagerd into
their proper destinations. (though, at this point, this might not even
be necessary - only if we still think that kio-extras, etc. are better
destinations than a kactivities-workspace)

** a separate repository kactivities-workspace would make this easier
dependency-wise

plasma <-- kactivities, kactivitymangerd, kactivities-workspace
kactivities <-- kactivitymanagerd (optional runtime dep, with cmake
check and warning)
kactivities-workspace <-- kactivities, kactivitymanagerd

^ a proper directed graph

Cheerio,
Ivan

--
KDE, ivan.cukic at kde.org, http://cukic.co/
gpg key id: 850B6F76