[RFC] Draft Roadmap for KDE 4.0

[Dirk Mueller]

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. 

Greetings,
Dirk