[QGIS-Developer] [Qgis-psc] QGIS and Qt 6: A proposal

[Matthias Kuhn]

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-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc