[Development] Abandoning the container changes

[lars.knoll at nokia.com]

Some comments to the thread as a whole:

Thiago did the call to not pursue the container changes any more for Qt 5
and propably had good reasons to do so. That implies that we'll continue
with the classes we have now (yes, with their downsides in some use cases
as well) for Qt 5.

The containers are actually not as bad as some of you make them sound. The
classes are stable and for many (most) use cases have a rather good
performance. So they are something we can live with for the next years to
come. Breaking BC again in a year from now just to make some container
classes 10-30% faster for isolated benchmarks is simply not worth it.
Inside an application the improvement is usually negligible and for the
few cases where it matters one can use specialized containers.

There's many more places where we can improve Qt a lot more (in a BC way)
then by changing our container layout again in a year from now.

Delaying further for such a change is also out of the question. The most
important thing right now is to get the new version out. Remember we're
doing a product which is a sum of many parts. We've done a huge amount of
new work with Qt 5. As long as we haven't done the 5.0 release all this
other good work not worth anything for our user base.

Cheers,
Lars



On 7/19/12 3:08 AM, "ext André Pönitz"
<andre.poenitz at mathematik.tu-chemnitz.de> wrote:

>On Wed, Jul 18, 2012 at 05:49:12PM -0600, Charley Bay wrote:
>> The "ideal" for me is that if container-changes would push the Qt
>> release back six months (to arbitrarily pick-a-fictitious-number), I'd
>> rather have a release now, and another release in six months.
>
>This was not meant to put anything on the critical path or to change the
>timing of Qt 5.0 at all.
>
>Andre'
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development