[RFC] KDE 4.0 Release Roadmap

[Allen Winter]

On Wednesday 14 March 2007 11:55:10 am Thiago Macieira wrote:
> Allen Winter wrote:
> >Howdy,
> >
> >Hereby we, the Release Team, present a draft KDE 4.0 Release roadmap
> > which has been discussed on our mailinglist the past few weeks. It's an
> > optimistic schedule that aims to release in late October, based on 3
> > Beta's and 2 release candidates.
> 
> Hello Allen
> 
> Thanks for being the spokesman. I want to start by saying thank you to you 
> and the Release Team for coming up with the plan.
> 
> I have no major problems with it. I'll point out the minor ones below.
> 
> >KDE 4.0 will not contain all features announced nor promised: these will
> >come during the lifetime of KDE 4.  We can probably switch quickly to a
> >KDE 4.1 release if there are major subsystems ready for merging soon
> > after the KDE 4.0 hits the streets. Also remember that we have been
> > porting for a couple years and we need to get this show on the road.
> 
> The discussion in the marketing mailing list seems to indicate that we can 
> deliver all features we promised for KDE 4.0. At least the hyped ones.
> 
Yes, we trust the marketing team to handle expectations.

> In any case, we should make it clear what is going to be part of the 4.0 
> release in the techbase website.
> 
And we need to start up a new Features page for 4.0.


> >  KDE 4.0 Roadmap
> >===============
> >
> >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?
>
Definitely stuff like Phonon and Solid.   The intention is we don't want anything that
causes major efforts to port, or to put things back to a compileable state.
We don't want any changes that require a couple days -> week of porting effort
any more past this date.

> 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).
> 
This is a close call.  I suppose the Core Devs really should decide.
By the spirit of what we had in mind, this probably should be in-place by 1 Apr.

> 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).
> 
This seems minor enough to be a 1 May thing.

> 
> >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.
> 
> Some things in my projects above require Qt 4.3 features. I cannot wait 
> until the soft freeze to merge those projects.
> 
I put the Qt 4.3 requirement at the Alpha Release stage because
I didn't know if it would be ready for the Subsystem Freeze on 1 April.

But the Core Devs can require it earlier than 1 May if so desired.
That doesn't break the milestone.

> > * 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 guess it means that the API shouldn't change without a darn good reason
and without the Core Devs permission.  I think adding a method here
and there for good reason would probably be fine.

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

> 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.
> 
I am already busting on the kdepimlibs people.  
kdepimlibs will follow the same milestones and rules as kdelibs.

Comments from the kdeedu and kdegames release managers?


> What I didn't comment on means I agree completely.
> 
Thanks for the detailed response.

-Allen


-- 
KDEPIM Developer
I accept PayPal payments to awinterz at earthlink.net