[Development] Feature freeze date?
morten.sorvig at nokia.com
morten.sorvig at nokia.com
Fri Dec 16 14:10:07 CET 2011
On Dec 16, 2011, at 1:37 PM, ext Jonas M. Gastal wrote:
> 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.
Well, yes and no. If every release is a (potential) feature release you do lose the ability to move to an earlier release without recompiling (forward BC). I don't see any reason why backward BC and source compatibility should be broken.
Morten
More information about the Development
mailing list