[Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released

[Thiago Macieira]

On Thursday, 8 September 2022 14:06:24 PDT Albert Astals Cid wrote:
> Should we restore those symbols or just accept that Qt 6 broke BC a year ago
> and no one realized so why bring the symbols back?

The commit message says 

    Remove the dead code for blocking methods from QtConcurrent
    
    After 79fd1cb2c631b6084bf10874205d27f5b53c907a the methods for running
    QtConcurrent algorithms in the blocking mode aren't used anymore. Since
    ThreadEngineBase and ThreadEngineStarter classes aren't meant to be used
    externally, it should be fine to remove startBlocking() methods now.

ThreadEngineBase is used only by ThreadEngine, plus its static 
ThreadEngineBase::threadPool is used by IterateKernel::forThreadFunction(). 
But ThreadEngine is a template class deriving from ThreadEngineBase, and 
IterateKernel is a template class deriving from ThreadEngine and that is in 
turn a base class for a lot of other classes.

Therefore, ThreadEngineBase is used by user code, only indirectly.

So the question is whether the removed function was ever callable in 
QtConcurrent from 6.0 to 6.3. The commit this commit refers to landed in 6.0. 
So if the commit message is correct, then there's no problem in Qt 6, because 
if something still called this function, it would have broken in this commit.

According to the Git log, 1bf75f2a661c05c7f1126187310d7df3f9704af5 is the only 
commit since Git tag v6.0.0 that touches a line that mentions "startBlocking". 
Therefore, there is no BC problem in Qt 6.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering