RFC: Creation of a new KDE SC module [kdeplugins]

[todd rme]

On Mon, Oct 11, 2010 at 3:41 PM, Sune Vuorela <nospam at vuorela.dk> wrote:
> On 2010-10-11, Martin Gräßlin <kde at martin-graesslin.com> wrote:
>>> If the effect library is still too unstable for separate things, it
>>> doesn't matter if it is a separate module or in extragear or on
>>> kde-look.
>> Of course there is a difference. The module would always be in sync with kw=
>> in=20
>> as it is released at the same time. That is something we cannot ensure in=20
>> kdelook or extragear, only in the SC. Btw KWin doesn't crash when there is =
>
> No. you also cannot guarantee that they are in sync with kwin if they
> are not build from the same tarball as kwin.
>
> Wether the extra tarball is released as a part of the 'engineering
> artefact' KDE SC or from another place is not relevant to what you can
> guarantee or not.
>
> /Sune

I would think most packagers would not try to mix the KDE SC 4.5
version of kwin with the KDE SC 4.6 version of plugins, for example.
There would be an expectation that the 4.6 version of plugins belongs
with the 4.6 version of everything else.  Of course they could do
otherwise, but in that regard it is no different than mixing, say,
kwin 4.6 with plasma 4.5.  There is a certain expectation that the
parts of an SC release belong with each other, and it is not safe to
use them with a different SC release.   There is no such expectation
with extragear, if I understand the discussion correctly.

I gather the whole point of this is to give a set of plugins that are
clearly and easily associated with a given SC release but are clearly
set off as an optional part of that release and can be easily not
included, as opposed to extragear (which has no general association
with an SC release) and the main modules (which are not clearly
optional).  Of course it is possible to combine any part of one SC
release with any part of any other (although it may not build), but
there is nothing unique about this proposal in that regard.

-Todd