> On Tue, Dec 17, 2024 at 9:17 AM Nyall Dawson via QGIS-Developer > <[email protected]> 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 [email protected] _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
