From kde-core-devel  Thu Feb 05 14:26:02 2004
From: Bo Thorsen <bo () sonofthor ! dk>
Date: Thu, 05 Feb 2004 14:26:02 +0000
To: kde-core-devel
Subject: Re: future versions (Re: [kde-announce] Announcing KDE 3.2)
Message-Id: <200402051526.08308.bo () sonofthor ! dk>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=107599122017163
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Boundary-02=_AKlIA70LyEgs3uB"

--Boundary-02=_AKlIA70LyEgs3uB
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
like:

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

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

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

Right now you can't run a KDE application without having both kdelibs and=20
base installed, and that is IMHO ridiculous. Doing the split I'm=20
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=20
many things in kdebase that are necessary. Which IMHO makes it even more=20
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=20
opportunity to do this. It would be a great move towards a more stable=20
platform to build applications on.

Bo.

--Boundary-02=_AKlIA70LyEgs3uB
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBAIlKAmT99lwfUS5IRAsmIAJ9oqaeJWuSBbNuxxoVVn0IVlQsfOgCeKtou
XEQkH5ex3f4bOjBqIR8CSE8=
=+/ew
-----END PGP SIGNATURE-----

--Boundary-02=_AKlIA70LyEgs3uB--