[Development] Spam: Re: Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

Volker Hilsheimer volker.hilsheimer at qt.io
Mon Jan 4 20:55:10 CET 2021

> On 4 Jan 2021, at 16:53, Bernhard Lindner <private at bernhard-lindner.de> wrote:
>> I’m not aware of a decision to break binary compatibility in Qt 6.1. The - so far - last
>> email to the respective discussion thread is
>> https://lists.qt-project.org/pipermail/development/2020-December/040763.html
>> and neither that nor any of the previous emails are conclusively stating that we do or
>> don’t break BC.
> If you are right, I got it wrong as well.
>> The topic in this particular thread is controversial enough as it is, let’s stick to the
>> facts :)
> This is a good idea all the time.
> Still Oswald was right. Qt 6 is a cripple (independent of the binary compatibility
> questions) and it was a wrong political and/or bonus driven decision to release it at a
> fixed date instead of asserting quality and completeness.
> We will see what kind of nasty compromises will be necessary to avoid breaking binary
> compatibility and if Qt will replace one evil with another by doing so.

The decision to release a reduced set of base modules first, and to follow up with functionality that is not part of the core of Qt over time, has been a good call, I think. Feature completeness was never the goal for Qt 6.0, and I don’t think it makes Qt 6(.0) a cripple, even though many projects will not be able to start porting until later. That’s ok, and was discussed and accepted during the last Qt Contributors Summit as well.

And asserting quality is not just a function of time either. The fact that we have all actively developed against the dev branches helped us discover issues early, and allowed us to fix them reasonably quickly. I personally think (and yes I’m biased, being the one pushing for moving away from the forward-merging way of operating) this has been a bigger contribution to quality and stability than another month or two of beta phase with very limited activity by the same small number of contributors and testers.

It seems that releasing a 6.0 was the best way to get more eyes and brains on Qt 6. Note that not breaking binary is a primarily political decision (esp if 6.0 is indeed a cripple and can’t be used by anyone for anything meaningful). And if that prevents us from taking the feedback that we can apparently not get via betas and RCs into account, then it’s just as bad as a bonus-driven release timeline would be.

FWIW, as I see it, the issues that have so far been raised as BiC-candidates [1] are IMHO not justifying breaking binary compatibility unless we really really want to. Valid objections have been raised in the respective thread.


[1] https://bugreports.qt.io/browse/QTBUG-89157

More information about the Development mailing list