Marius Storm-Olsen wrote: > On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote: >> 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. The value of having a long lived (5 years?) >> binary compatible 5.x series is (IMO) low as there are quite often >> other reasons to recompile the stack. > > If there's reasons to break BC, there's reasons for a new Major > version. We don't circumvent the policies because is looks silly to > have a new major version in such a short time after 5.0.
Agreed. > However, I can imagine there's other significant changes we'll notice > after 5.0 which will warrant other BC-incompatible changes, and maybe > we'd want to refactor out more of the modules from QtBase into their > own repos? As such, we might have several valid reason for having > another major, to "quickly" correct learned lessons from Qt 5, and to > ensure Qt 6 can live on for a very long time. Yes, by all means when we notice these needed changes and have them ready let's bundle them together and call them a release. Let's not plan releases based on features and let's not plan to do work based on the assumption that "we're doing a binary break anyway", at least for as long as we can avoid it. > Still, if Qt 6 would be on the road-map then, we should aim for making > transitioning as simple as a pure recompile. We don't _have_ to do > significant restructuring just because we're going a new major. Simply > saying that we need to do it because of BC issues is fine. If major > speed improvements is a result of that, I'm sure many people would > understand. Agreed. > Anyways, several people and Thiago himself has said that now is not > the time for such a change to our tools classes, and we should listen > to that. I don't think you want to add them both and let the end user > decide, as it will create a maintenance nightmare, and you will have > applications which both use Qt 5 but are incompatible with each others > run-time. (Some apps will demand that you use the "optimized" Qt5 for > plug-ins etc.) My suggestion is not to have both variants in the common code base or to advertise two alternative Qt 5 implementations. I'm suggesting we treat this as feature development happening in a feature branch (reviewed, CI-tested and all that, if feasible). I'm also suggesting we consider the posibility of doing an earlier BC break with stronger SC guarantees and use that if/when there's significant value being added. Having this *possibility* at all can encourage people to try out things, instead of waiting for a Do Never Qt 6 (tm) release and rushing half-baked features out. João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development