[Development] Abandoning the container changes

joao.abecasis at nokia.com joao.abecasis at nokia.com
Thu Jul 19 01:56:31 CEST 2012


Marius Storm-Olsen wrote:
> On 18/07/2012 02:06, ext joao.abecasis at 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



More information about the Development mailing list