[Development] Feature freeze date?

[lars.knoll at nokia.com]

On 12/16/11 10:10 PM, "ext morten.sorvig at nokia.com"
<morten.sorvig at nokia.com> wrote:

>
>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.

IMO there is another problem with this. We'll get too many feature
releases, making it hard for developers to keep track of the feature set
that's available. In addition, it's difficult to implement that model
until you reach a very high coverage with automated tests, as the 6 weeks
don't leave you a lot of time for regression testing.

Cheers,
Lars