[Development] Feature freeze date?

[morten.sorvig at nokia.com]

On Dec 16, 2011, at 3:01 AM, ext jason.mcdonald at nokia.com wrote:

> Having been release manager for several past Qt feature releases (4.5 to 4.7), I'm wary of setting a single feature freeze date and having a big rush to cram all the new features into the master branch in the last couple of days before the deadline.  Instead, I would like to see a staggered delivery of features, where each large change is tested, merged and tested some more before the gate is opened for the next big change.
> 
> For the Qt 4.5.0 and 4.6.0 releases, we did the former, and in both cases the last minute rush to push in all the new features caused substantial breakage and significantly delayed the alpha and beta releases.  For Qt 4.6, it took two weeks after the feature freeze date to get the branch compiling again on all the Tier 1 platforms (that was the criteria for an alpha release) and several months to satisfy the (fairly lax) quality criteria for a beta release.
> 
> For the Qt 4.7.0 release, we staggered the merging of new features over several weeks and had a much better result, with alpha release packages building successfully on the day after the feature freeze.


I think staggering of feature integrations is a very good idea in general. Qt 5.0 is a special case since we are looking at features that cannot be done for 5.1 due to BC reasons.

Changing the topic slightly, what if we removed the need for common feature freezes?

In the Chrome release process a new release cycle starts every 6 weeks, and both features and bug fixes are eligible. The release process consists of several channels that the release propagates through: new code spends 6+6 weeks of testing and stabilization in Dev and Beta before being released in the Stable channel. (The channels overlap: there is always a release in the Beta channel for example.)

This would remove the pressure to get a feature done in time for a release. If you miss a release cycle a new one starts 6 weeks later - no big deal. It also means that already finished features can be released in a timely manner and are not held up by other unfinished features that need to go into the same release.

Removing the difference between feature and patch releases is certainly something we have to think carefully about, but I do think that the benefits of having a "clockwork" release model wold be a benefit to Qt as it becomes an open project.

(Presentation on the Chrome Release Cycle: https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch)

Morten