[RFC] KDE 4.0 Release Roadmap
winter at kde.org
Wed Mar 14 18:39:53 CET 2007
On Wednesday 14 March 2007 11:55:10 am Thiago Macieira wrote:
> Allen Winter wrote:
> >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
> > * 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
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
> > * 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
> 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.
I accept PayPal payments to awinterz at earthlink.net
More information about the release-team