[RFC] Draft Roadmap for KDE 4.0

[Tom Albers]

Hi Dirk,

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 ;-)

Toma

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. 
> 
> Greetings,
> Dirk
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team