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