Singing in tune

Sebas, Tom and Aaron discuss a regular 6 month release cycle. This was first brought up in Mark Shuttleworth's keynote at Akademy 2007. The relevant section starts around 30:00 and in the questions at 42:00. There was more to his argument than just "release every 6 months". The exact time delay was a detail, albeit an important one. For the benefit of those who weren't there and perhaps also those who were, I'll summarize his points:

• Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure. It allows projects up/down and across-stream to plan better and co-operate more efficiently.
• If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release. Consequently, new releases will get to users faster and hence feedback from recent developments will get back to developers faster. Gnome already benefits from this trust.
• Getting the release out is the most important feature.
• It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack. This synchronization may be explicit or it may be "coincidental" (if arranging and publicly announcing such co-operation is unpalatable for whatever reason)
• Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration, as opposed to dividing up the 6 months into slots of X months feature development, Y months bug fixing, Z weeks releasing. The kernel developers have proved that this approach can work.
• The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)
• The value of synchronization is sufficiently high that it may justify re-arranging the structure of a big project to accommodate it.
• The time delay is subject to debate. Ubuntu found that 6 months works well for them because, for example, it divides evenly into a year so holidays etc. can be planned around it. The appropriate delay depends on where a project is in the stack and what its up/down and across-stream are doing. Further upstream projects can generally get away with a shorter delay because there is of the buffer provided by downstream.

From what I recall, there was a general consensus amongst attendees in favor of the idea - which left the details to sort out. My personal experience with large projects is limited but I think the above arguments are good, particularly the key first point and the evidence from projects which have tried to follow this approach is positive on the whole.