[QGIS-Developer] QGIS 3.46 builds to use Qt6?

[Julien Cabieces]

> On Tue, Dec 17, 2024 at 9:17 AM Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>
>  I'm SO strongly against breaking QGIS API unless we ABSOLUTELY have
>  to. The pain of the 3.0 transition is still relatively fresh in my
>  memory, and I think we would be doing our users and end user
>  organisations a great disservice by moving to QGIS 4.0 now.
>
>  I think a 4.0 API bump should be an absolute last resort, when we have
>  no other option.
>
> Agreed, and compared to transition from QGIS 1.x to 2.0 or from 2.x to 3.0, we don't have a long list of QGIS API cleanups, and Qt has
> also been much more conservative with API breaks in Qt 5->6 transition compared to Qt 4->5.
>

But there are still many breaking changes (see pyqt5_to_pyqt6.py) and
there are high chances that any plugin would require a migration step
for Qt stuff, so it could have been a good opportunity to take care of QGIS
deprecated API at the same time. We could have also wait for 4.2 or 4.4 to
really remove those deprecated APIs.

I'm afraid that the proposed policy (having 2 versions, 3.46 becoming the
Qt6 more stable one, and Qt 5 less stable one but
supporting non migrated plugin) would not be not clear enough. From a
developer perspective, I'm used to all of this but I'm wondering if users
would completely understand it (the number of times I have to explain our
release cycle/LTR, and our roadmap page...).

And there is also the issue with migrated plugin which may use new Qt 6
API and would become non working in Qt 5 version. So you could end up
with some plugins working only with Qt5 and some with Qt6. That's maybe a
tiny non important spot.

But maybe good communication would be enough to avoid all those issues.

>  
>  > Regarding the proposal of having 2 versions (Qt 5 and Qt 6), I'm not
>  > completely sure this is a good idea. I'm afraid that plugin developer
>  > would delay the plugin migration if this is still possible to run a QGIS
>  > with Qt 5.
>
>  Well, that's entirely their choice. But I'd imagine end user pressure
>  would result in the majority of frequently used plugins being upgraded
>  quite quickly. And if a particular plugin ISN'T compatible with the QT
>  6 builds, then the user who requires that plugin could still run the
>  Qt 5 build for the foreseeable future.
>
> My suggestion would be that we nudge plugin developers in some ways during the months before the official Qt6 build arrives, for
> example:
> - show a note in message bar upon QGIS start if some of the active plugins are not ready for Qt6
> - show a warning in QGIS plugin manager for plugins that don't support Qt6 yet (on Qt5 builds as well)
> - warn developers when uploading a plugin version that does not support Qt6
> - send regular (e.g. monthly) emails to plugin developers noting they should add Qt6 support
>
> And at some point later (e.g. a month before the official Qt6 builds), we should probably not allow uploads of plugin versions without Qt6
> support...
>

That are good proposals, I agreed

> Cheers
> Martin

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com