Sebas writes a tremendously great blog, in my opinion, on the issues we face with a 6 month cycle. Please go and read it, as he really gets the issues at hand on all sides.

Sebas also proposes the rather radical idea of, "What if we never froze trunk?" Or, as he put it, "always summer in trunk".

My dream situation would be to have 2 weeks of devel, 3-4 days minimum to stabilize that work (but longer if necessary), rince and repeat with natural breaks for things like life's little interferences, bug fixing orgies and what not. I think we'd find a natural cycle where significant feature improvements would land every quarter or so.

At each known stable point we'd push the changes in the branch back to mainline for others to use and test. The beauty here would be that other developers and testers wouldn't get horrible breakage periods, just steps from relatively stable to relatively stable.

When a release time comes up, we'd sync the last stable point to the release branch and continue on working. No further syncs would happen until the release process of betas and RCs was over, at which point we'd sync up again at the next stable point.

Bugs and other issues that come up during the release periods would be addressed and backported, just as we do for minor releases (though in the other direction).

It would allow KDE to do whatever release cycles the umbrella project wanted while allowing us to breath, as Sebas put it so eloquently, to our own heartbeat.

My hope in discussing this is openly is that we can make necessary changes to allow the above utopia to occur. Maybe not today, or even for 4.2. But eventually. It probably means using a tool that is better than the current svn release (I see a number of improvements in svn 1.5; maybe that will be enough? I'm doubtful, but also hopeful), it means making release branch development not the norm (which it is today) and it means trusting our own rhythms. Such an approach is applicable to far more than just Plasma; many of the more interesting application in KDE's svn face these same issues.

At the same time I don't want to see KDE's development become a difuse diaspora of repositories and chaos. We can come up with best practices together and find a way to satisfy both the release desires of downstream and the development desires of upstream (that's us =)