[RFC] KDE 4.0 Release Roadmap

[Tom Albers]

> >Milestone: Subsystem Freeze
> >Date: 1 April 2007
> >Goals:
> > * From this date forward, no major KDE subsystem can be committed to
> > kdelibs. 
> 
> What do you understand as major subsystem? Things the size of Phonon and 
> Solid?

Yes. Things that effect large pieces of code.
 
> Because I have two in mind:
> 1) KNetwork's replacement. I wouldn't call this a major subsystem: I would 
> call it a minor wrapper around QtNetwork. The current subsystem 
> (KNetwork) will simply be removed without going to KDE3Support because I 
> won't maintain it (and because you cannot use two independent resolver 
> subsystems in the same application on non-Linux systems).
> 
> 2) I have an idea in mind for KIO::Connection, which won't go higher than 
> KIO::Job. This is all backend stuff and may or may not have impact on the 
> front-end. If it does, it'll be minor (i.e., remove the command ID 
> constants from the public headers).
> 
> Would those be considered major subsystems?

I don't think it's a problem when you announce it up front (like now ;-)) and the impact is relatively small. The further in the process you get it ready, it seems logical you help port the effected applications in that area. Ideally only add classes, don't remove any ;-)

> >Milestone: Alpha Release + kdelibs soft API Freeze
> >Date: 1 May 2007
> >Goals:
> > * Qt 4.3 is required from here until release.
> 
> 1 May is too late to *start* this requirement. I agree that by 1 May, it 
> will be required. But I need to start requiring it before.

The intention was to indicate 4.3 will be used for alpha 1. 

> Some things in my projects above require Qt 4.3 features. I cannot wait 
> until the soft freeze to merge those projects.
>
> > * The kdelibs API is frozen. This means that the classes and interfaces
> > are not allowed to change, except with permission of the core
> > developers. 
> > * To make an API change, post a kdelibs API exception 
> > request to the kde-core-devel mailinglist with an explanation and the
> > code. If there are no objections after a week, the change can be
> > committed. NOTE: all affected modules must continue to compile and work
> > as expected.
> 
> Makes sense.
> 
> By "API change", do I understand correctly "source- or binary-incompatible 
> change"? If so, we'd still be allowed to complement the API, provided we 
> don't change what's already there.

I can hardly see an objection to it...
 
> >Milestone: Beta Cycle, Full kdelibs API Freeze
> >Start: 25 June 2007  End: 24 September 2007  Duration: 3 months
> > (estimated) Goals:
> > * From this date forward, a Beta Version will be published every month
> >   until most grave bugs are resolved.
> > * The kdelibs API is now frozen solid.
> 
> I think this freeze might include libraries in other modules. Probably by 
> the Feature Freeze time, we'd make a list of libraries in such 
> conditions.
> 
> I was especially thinking of kdepimlibs, but it'll depend mostly if that 
> module will follow the release schedule. In any event, we have libraries 
> like libkdeedu and libkdegames that will probably have to freeze.

Yes. I think those libs should follow kdelibs' schedule...

Toma