> > 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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
