Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
On Thu, 8 Sept 2022 at 18:39, Thiago Macieira wrote: > > On Thursday, 8 September 2022 14:30:36 PDT Albert Astals Cid wrote: > > Oh, sorry for the noise. > > No need to apologise. Better to have more a false alarm so we can be sure, > then allow a problem to linger. More eyes on the problem. Ditto. Normally that kind of thing ought to be checked when doing the Debian packaging (the build will fail), but we are all humans and we might easily confuse something... We haven't done 5.15.6 yet, of course. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
On Thursday, 8 September 2022 14:30:36 PDT Albert Astals Cid wrote: > Oh, sorry for the noise. No need to apologise. Better to have more a false alarm so we can be sure, then allow a problem to linger. More eyes on the problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
El dijous, 8 de setembre de 2022, a les 23:23:00 (CEST), Thiago Macieira va escriure: > 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. Oh, sorry for the noise. I did not realize 1bf75f2a661c05c7f1126187310d7df3f9704af5 and 79fd1cb2c631b6084bf10874205d27f5b53c907a where so apart in time. "Good", then the only issue is in Qt 5.15.6 I've reverted the patch removing those functions in the KDE Qt Patch collection to restore BC, those that care about BC are welcome to use it. Cheers, Albert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
El dimecres, 7 de setembre de 2022, a les 14:16:23 (CEST), Tarja Sundqvist va escriure: > Hi all, > > > > we have released Qt 5.15.6 opensource today: > > > > * release note: > https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.6/release-note. > md * source packages in download.qt.io: > * https://download.qt.io/official_releases/qt/5.15/5.15.6/ > * > https://download.qt.io/official_releases/QtForPython/pyside2/PySide2-5.15.6 > -src/ * Git: clone the release with the tag v5.15.6-lts-lgpl > This Qt release comes with a binary incompatible change in this commit https://code.qt.io/cgit/qt/qtbase.git/commit/src/concurrent?h=v5.15.6-lts-lgpl=4d6752e8d2ed9d303befe7adf7f6e4b6ba16bbb9 Example of that symbol being used in the wild $ nm -D -C /usr/lib/qt/plugins/ktexteditor/kateprojectplugin.so | grep -i startBlocking U QtConcurrent::ThreadEngineBase::startBlocking()@Qt_5 This is due to the code calling QtConcurrent::blockingMap and blockingMap using startBlocking from a template. This binary incompatible change also existed in the Qt 6.3 release in the shape of commit 1bf75f2a661c05c7f1126187310d7df3f9704af5 I guess there's no one using Qt 6.x that cares about Binary Compatibility so it wasn't found. 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? Cheers, Albert > > Best regards > > Tarja Sundqvist > > Release manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
On Thursday, 8 September 2022 02:23:39 PDT Edward Welbourne wrote: > The reason we plan for Qt 7 is that it's the next time we can make > certain kinds of backwards-incompatible changes. When we decide that > such a change is needed, we plan for it, because we can't do it yet, or > indeed any time soon. Particularly because we realised that we did not do all the "### Qt 6" changes for 6.0. This time around, we're actually making the changes right now. Many of the changes can be added to Qt 6 itself, if they are simple overloads, and those benefit most people. Some others can't and must instead be hidden with #ifdef. The point of this thread is to discuss what work we should do now, if neither option above can apply or if it becomes too ugly to maintain. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
Nicolas Fella wrote: >> The fact that KDE does not use Qt6 yet has rather little to do with >> the quality of Qt6. Kevin Kofler (8 September 2022 01:37) replied: > Where have I claimed that it does? I sense a strawman… > > My point is that it takes time for KDE and other downstreams to adopt > a new major release of Qt, no matter the reason why it does, and that > moving on to Qt 7 before or shortly after the downstream consumers are > ported to Qt 6 would be very unhelpful. Well, since you brought up the strawman, where exaactly did anyone claim Qt 7 was in any sense so imminent that it'd be "before or shortly after" KDE has upgraded to Qt 6 ? Please do not mistake long-term planning for an intent to release what we're planning any time soon. I don't know what the plans for the major version cycle currently are, but the roadmap for the foreseeable future is all about continuing releases of Qt 6. The reason we plan for Qt 7 is that it's the next time we can make certain kinds of backwards-incompatible changes. When we decide that such a change is needed, we plan for it, because we can't do it yet, or indeed any time soon. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
