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.cu...@kde.org, http://cukic.co/ gpg key id: 850B6F76 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
