Change release schedule 4.2 and schedule for 4.3

Tom Albers tomalbers at
Mon Sep 8 21:09:41 BST 2008

At Monday 08 September 2008 21:44, you wrote:
> On Monday 08 September 2008 20:08:50 Aaron J. Seigo wrote:
> > of course, the release team has already changed that with a non 6 month
> > period for 4.2. so there is obviously flexibility. it's just a question if
> > whether being flexible because of the timing of Akademy is more or less
> > useful and important than current schedules projects such as PIM and Plasma
> > have already lid out and taking advantage of Qt 4.5.
> I agree on the whole mail, and on this part I have to comment that if we're 
> going to switch to git by March/April (and count me in to make this migration 
> happen) and we can implement the always-autumn-in-trunk plan, we can have, as 
> sebas puts it, both the cake and eat it. Plasma and PIM will be able to use 
> 4.5 and people will be able to hack like crazy on new features; no matter when 
> Akademy happens.


I think you are missing the point. The always summer in trunk does not mean we do not release anymore. So there will still be beta tagging, etc. The problem with the akonadi sprint was that it was between beta1 tagging and the release of beta1. So they either hack in a separate branch and miss the beta1, meaning no beta testing by users. Or delaying beta1 for kdepim / kdepimlibs, which does not make sense either. 

So switching to git does not have any effect to the release planning in my opinion. But your mail exactly address my concerns with the always summer in trunk. People will hack on features and are not easily persuaded to recompile all of kde to test the stable branch or do bugfixing. This 'problem' is nowhere near properly addressed in my opinion, but we lack a good mailinglist to do that on ;-)



More information about the kde-core-devel mailing list