future versions (Re: [kde-announce] Announcing KDE 3.2)

[Bo Thorsen]

On Thursday 05 February 2004 14:23, Marc Mutz wrote:
> On Thursday 05 February 2004 12:28, Waldo Bastian wrote:
> <snip>
>
> > I think so, yes. With the schedule that I proposed the
> > framework/kdelibs people can start preparing for KDE 4.0 already and
> > the applications developers can continue working on their apps for
> > 3.3 without getting disturbed by tons of changes in the libs that
> > way.
>
> <snip>
>
> I know that I'll be dismissed as a heretic for this, but how about KDE
> 3.3 didn't include kdelibs for a change, but focused on applications?
>
> That KDE release would require kdelibs 3.2 and kdelibs HEAD could
> undergo a healthy API cleanup (not to say "revamp", looking at some
> classes like KDialogBase) and be next released with KDE 4.0?
>
> I think KDE should start faster release cycles for the application
> modules and back up a bit on framework releases. 1+ year cycles for
> kdelibs and ~6 months cycles for applications would create a climate
> where applications could progress faster and the framework be more
> polished. This is because on the app side, you get user feedback
> faster, and on the libs side, you need to think twice before adding
> something to it if the next kdelibs release won't be in time for the
> next release of your app. New classes could prove themselves in the
> lib<module> libraries before being moved to kdelibs.
>
> Something like the K*Config* chaos could have been prevented by such a
> development model and thrid-party app developers wouldn't need to worry
> about framework API instabilities so much.
>
> KDE as a whole might want to wait for the results of the test case
> "kdepim", though, before adopting that model for all app modules.
>
> And yes, I'm well aware of the khtml problem. Which might just be an
> indication of the fact that khtml better be a module of it's own.

I already tried to argue for redoing the packaging of KDE to be something 
like:

kdelibs: Current kdelibs + parts of kdebase (kioslaves, l10n, most of 
kcontrol...). This would be everything needed to run a KDE application.

kdesktop: The parts needed to run KDE as your desktop - or everything that 
isn't needed for some application to run. (kwin, kicker, khotkeys, 
ksplashml, wallpapers, kscreensaver, ksmserver...)

There are only a few actual applications in these two modules (konqueror 
and konsole). I don't know what to do about these - a kdeapps module 
could be one solution.

Right now you can't run a KDE application without having both kdelibs and 
base installed, and that is IMHO ridiculous. Doing the split I'm 
advocating here would make it *much* easier to follow marcs proposal.

It's actually not that far off being the case already; there are not that 
many things in kdebase that are necessary. Which IMHO makes it even more 
compelling to fix the current state. And I do mean "fix".

Please think more about it - with the upcoming 4.0, there's such a nice 
opportunity to do this. It would be a great move towards a more stable 
platform to build applications on.

Bo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040205/17fb45c2/attachment.sig>