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 [EMAIL PROTECTED] _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
