Hi Nyall, Having a clear plan in time for Qt6 is important. Thanks.
Some questions: - Is there any plan regarding the todos for QGIS 4? - Do we also remove/cleanup our own deprecated methods, and if yes, when? Thanks Matthias On 7/6/20 12:44 AM, Nyall Dawson wrote:
Hi lists, I'd like to raise a proposal which has been percolating away in the back of my mind for the last month: Background: 1. Qt 6 is coming, and it's coming relatively soon (before end of year). 2. Qt 5.15 is the final Qt 5 release. It's officially an LTR release, but in reality -- it's not, due to Qt upstream changes which mean that as soon as Qt 6.0 is released they will stop providing public updates to Qt 5.15. At this point (and in the absence of any community fork), Qt 5 is effectively EOL. 3. We have some big hurdles approaching on which we'll be completely dependent on upstream Qt. Probably the most important of these being Apple's move to their own CPU architecture. If we don't move to Qt 6.0, then QGIS is DOA when the new Apple hardware starts selling. 4. Last time we had to tackle this situation (Qt5) we bumped QGIS to a major release (3.0) and broke API for plugins. This caused a lot of **COMPLETELY NECESSARY AND 100% JUSTIFIED** pain for both users and plugin developers. We should try and avoid repeating this unless we have absolutely no other choice. 5. We waited far too long to move to Qt 5. (it was around the ~Qt 5.7/5.8 release before we jumped). We risked being kicked out of debian because of our much delayed transition. We also had a period of many many years before we could take advantage of upstream Qt improvements and bug fixes as a result, which has directly lead to a culture of ignoring Qt upstream in QGIS development and implementing fixes/improvements as downstream "hacks". 6. The QGIS 2.x -> 3.x transition was extra complicated, in that it also involved the Python 2->3 transition. Thankfully, there's no sign of Python 4.0 on the horizon ;) 7. Qt upstream have repeatedly pledged that Qt 5 -> 6 will be a "soft break", where they are minimising the changes required by applications to transition. In fact, they've pledged that any code which builds without deprecation warnings in Qt 5.15 WILL build and run without issue in Qt 6. ------- Proposal: ------- 1) Following the release of Qt 6.0, we then require QGIS 3.18 and above to be usable under both the Qt 5 and Qt 6 versions. 2) We classify this as a "soft break" for plugins -- we do NOT permit and breakage of the existing QGIS 3.x stable api, so the only work required for plugins is to ensure that the are not using the API declared as deprecated in Qt 5.15 and can run correctly under either a Qt 5 or Qt 6 build of QGIS. Based on what it's required so far to remove the deprecation warnings from QGIS itself, this should be minimal work for plugin authors. 3) We make a concentrated effort prior to the release of Qt 6.0 later this year to clear all the remaining deprecation warnings from QGIS, so that we're ready to switch as soon as possible 4) We provide a summary guide for plugin authors to advise them of the steps required to upgrade the deprecated Qt 5 API calls This proposal should minimize harm to plugin authors, while still permitting us to stay current with upstream Qt releases. We'll be able to continue the current focus of upstreaming fixes and features to Qt itself, and also will be fully prepared to start building QGIS for the new Apple architecture (as soon as Qt 6.x and all our other dependancies are available for the Apple CPU, that is!) Thoughts? Nyall _______________________________________________ Qgis-psc mailing list qgis-...@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-psc
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer