[Development] Abandoning the container changes

[Charley Bay]

>
> João spaketh:

>> I think it would be feasible to do a binary-only break somewhere
> >> around the 5.2 timeframe (say, ~12 months) where we address this.
> >> Technically, this would be Qt 6, but user porting effort would be
> >> reduced to a recompile.
>


> André  respondeth:
> > That's essentially option (D) with a somewhat longer lead time.
>

João respondeth again:

> Somewhat. If it's a binary break we should still call it Qt 6.
>

>  I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to

feedback and generally (im)prove on the Qt 5 vision. Some container
> changes sneaked in, but they're not what we're trying to deliver *now*.
>
> In parallel, we actually write the container changes everyone's up in
> arms about (Thiago's changes are unfinished and not-fully-published work
> in progress), we review those changes, take them for a spin, kick the
> hell out of those tires and then make an informed decision whether it is
> worth the binary break and how to handle it, in case it is.
>
> Besides autotests coverage, we also have no benchmarks showing
> improvements. I assume we can see improvements for the inlining of size
> and offset/data in iteration benchmarks, but we haven't fully explored
> the impact of *growing* the size of the container itself.
>
> Anyway, we can discuss potential options now, but we can't make any
> decisions and can hardly make commitments, other than than "let's do the
> container changes and release them when they're ready".
>

IMHO this seems reasonable.

I view QML2 as the "stabilized" version of QML1 (significant technical
differences, as well as underlying implementation).  I was quite impressed
with what QML1 offered (it's a new paradigm), but I think the community
would benefit from learning-to-work with QML2 as opposed to extending their
learning curves on QML1.

I understand the value of the container-changes, and while warranted, it
doesn't seem to be the biggest part of the core-offering of Qt5, and it's
possible some of the benchmarks/changes associated with that effort might
be better understood after the C++11 Rvalue-references are better
implemented and made available through compiler vendors.

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.

I know it's been discussed before (don't want to re-open that discussion),
but I don't care about binary compatibility (I know how to recompile); and
only somewhat care about interface compatibility (adding-member-functions
seems incredibly cheap to me, I'd prefer to have the APIs mature properly
since they represent new designs); and, I'd support any
"renaming/refactoring" to enforce best-practice-use-models as these are
"discovered" when applying this new paradigm.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120718/34bb98a6/attachment.html>