On Friday 16 December 2011 08:40:24 [email protected] wrote: > 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 > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development
I don't see how to do that without breaking the source and binary compatibility promises, which I think are very important. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
