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

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu February 5 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?

Yes, I'm all with you, but at the moment khtml is a problem as you point out 
already and their are probably enough other areas in kdelibs that need some 
continued maintenance work as well. So I don't think it is practical to skip 
kdelibs 3.3 altogether.

> 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.

I think we can move in that direction already, even with a 3.3 release of 
kdelibs, by means of policy: we can require that all applications be 
compilable with kdelibs 3.2 for the time being and we can put kdelibs in an 
API freeze relatively quick for 3.3.

I'm not in favor of too much revamping for KDE 4.0 because that tends to give 
application developers only more work to do without getting much in return. 
It will take longer for development books to catch up, etc. etc. Having to 
make changes for Qt4 sounds already bad enough.

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SUSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAIlkdN4pvrENfboIRAid4AKCo+jCzW3lrkeBFR48amx7SZDdL1ACdHLOe
V5fwTF4DjFFGTjN8hSE4QSI=
=z82G
-----END PGP SIGNATURE-----