Plugin/Addon-Modules (was: Re: Squeezing "Show Keyboard Status" indicator into KDE 4.2)

[Friedrich W. H. Kossebau]

Am Montag, 5. Januar 2009, um 22:20 Uhr, schrieb Thomas Zander:
> On Monday 5. January 2009 19:28:27 Sebastian Kügler wrote:
> > > personally i don't think there's a lot of reason for another module,
> > > though.
> >
> > Or maybe intermittent releases of kdeplasma-addons? Like once every two
> > months, with two weeks of freeze? Would make for nice testing ground of
> > seasoned releases as well ...
>
> In KOffice that plan was also aired (a bit optimistic, I know) that we
> could have the main suite have a yearly release (historical reasons) and
> all the plugins we expect to get have a much more frequent release
> schedule.
>
> Makes sense to me.

It would also mean a smaller "time to market". Which might be especially 
encouraging for new contributors, who participate with little plugins or 
other things which are quickly developed, and only a few month later can 
say "hey daddy, this was done by me, I'm part of KDE!"
Those little things usually only get a short time span of attention. And as a 
release has some kind of disciplinating effect (oh, only two more weeks, so 
let's polish it now, because it has my name on it), chances are higher it 
does not get dropped by the time, perhaps. And the next release is always not 
too far away, so this motivation comes more often.

Some loud thinking:
[split between base and plugins]
As branching for the more frequent releases of the plugins should not also 
always branch the base, this would mean a split of all modules in 
platform/framework/base-program and the plugins. Such a split, even done for 
other reasons, has already happened for some, see kdebase/workspace vs. 
kdeplasma-addons (yes, ignores the base applets), kdevplatform vs. kdevelop.

[API/ABI]
Some programs support plugins, but without a finished interface. As long as 
the plugins are living in the same module and are adapted to all changes of 
the program, this is no problem. But once the plugins are in another module, 
the interface becomes semi-public. So the API stability policies need to 
allow the break between minor releases for these semi-public APIs. Should be 
no real problem, as usually everybody updates all of the KDE modules 
together.

[Version numbers]
For large releases which include the base programs all modules should share 
the same version numbers. I think this has worked nicely in the past, makes 
dependencies easy to see and also improved the thinking of the KDE software 
as a consistent suite.
So while the plugin modules increase their minor number by 1 for each release, 
the base modules would synch their minor number to that of the plugin modules 
for the next release.

[Rather external/addon plugins]
But then, how large is the demand for this? And isn't the co-development 
between base and plugins something which should not be underestimated in its 
fruitfulness? So perhaps not all plugins should be moved to the plugin 
modules. It could rather serve for those by-now independent developers who 
develop on their own and just publish to e.g. kde-apps.org. See yourself:

Service Menus: http://www.kde-apps.org/index.php?xcontentmode=287
Kate plugins: http://www.kde-apps.org/index.php?xcontentmode=241 (not all)
Amarok 2.0 scripts: http://www.kde-apps.org/?xcontentmode=57
...
While GHNS could be used for the cpu-independent plugins, still they miss the 
excellent infrastructure for development inside the main KDE project, like 
translations, artwork, peer-review, and release management.

End of brain dump. Afterall, someone has to implement it, push this forwards, 
and do all the work for the extra releases. And that won't be me, currently. 
I am already more than grateful enough for all those who run the 
infrastructure and all, thank you :)

Even more, Okteta will only have a plugin infrastructure for at around KDE 
4.4, so why should I care now ;)

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta