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

[Marc Mutz]

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.

Marc

-- 
"Similia similibus curentur"
           -- Bush's new motto in fighting terrorism.