[RFC] Draft Roadmap for KDE 4.0
tomalbers at kde.nl
Wed Mar 7 22:02:08 CET 2007
Many thanks for those points, I will make a new schedule in the weekend with all comments in there.
I wanted to avoid 1st april as it's a special date, but that's not a real good reason ;-)
Op wo 7 mar 2007 21:52 schreef u:
> On Saturday, 3. March 2007, Tom Albers wrote:
> Hi Tom,
> Thanks for your schedule proposal, and sorry for me following up on it late, I
> was quite sick the last week and only now manage to catch up.
> > kdelibs soft api freeze + alpha1 release - 2 April
> > This is the the point where kdelibs api is frozen. That means that the
> > classes and interfaces are not allowed to change anymore. That means the
> > end of the famous bic Mondays.
> I'm fine with the date, but I wouldn't restrict binary compatibility as the
> first thing. binary compatibility is not of a big concern during development.
> A good milestone would be:
> - no major subsystem / class set will be merged anymore for KDE 4.0 into
> kdelibs. This especially means that all the plasma stuff, at least the part
> that is ending up in 4.0, has to be in by that time.
> BTW, since its again this year: I would like to release alpha1 on April 1st.
> that means tagging a week before that.
> > kdelibs is also i18n frozen, exceptions can be asked on kde-i18n
> > mailinglist. The release will not include translations.
> freezing i18n on kdelibs doesn't make sense. there isn't much i18n there. it
> would be better to define a freeze date for the "desktop", that is workspace
> and everything it depends on.
> > feature freeze - 2 may
> > After this date the kde main modules are frozen for new features. No new
> > features are allowed, the focus is from now on on stabilizing the
> > applications and fix all bugs. This is also the date that all the
> > maintainers of the main kde modules need to indicate if they will follow
> > this schedule or will divert and will not be released together with kde
> > 4.0.
> what are the main modules and what is part of KDE 4.0 ? for example it would
> be a bad idea if kdebase or kdepimlibs is going to divert from the
> schedule ;) BTW, we should split kdebase into base and workspace.
> > message freeze - 2 June
> > After this date the main modules are frozen for new messages. Exceptions
> > can be asked on kde-i18n mailinglist.
> message freeze before beta1 doesn't make sense. message changes have to
> incorporate testing feedback. therefore message freeze should be around
> beta2, not before beta1.
> > >From this date on every month a beta version will be published, this will
> > > be repeated until most grave bugs are resolved. Translations are included
> > > from the second beta. kdelibs api is now frozen.
> > release candidate cycle starts, total release freeze. - 2 September
> > A RC will be released. If there is no grave bug in that release, kde 4.0
> > will be released, else new release candidates will be released every month.
> A month is too much for a release candidate. if we're confident that it is
> good enough for a .0 release, then two weeks is usually enough.
> > When the first release candidate there is a total release freeze active.
> > This means that you can fix serious bug reports but nothing else.
> "serious" isn't a very clear term. I would prefer to call it "regression fixes
> only". if it was broken with 3.5.x, then so be it.
> > KDE 4.0 - 2 October
> This is a bit ambitious, but I'm totally fine with it as a target. We'll
> eventually have to slip it anyway a little.
> release-team mailing list
> release-team at kde.org
More information about the release-team