[Development] Feature freeze date?
Jonas M. Gastal
jgastal at profusion.mobi
Fri Dec 16 13:37:04 CET 2011
On Friday 16 December 2011 08:40:24 morten.sorvig at nokia.com 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
> Development at qt-project.org
> 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.
More information about the Development
mailing list