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

[Bo Victor Thomsen]

 From a plugin developer's viewpoint:

 1. It's basically a good idea to keep supporting libraries (like qt)
    up-to-date version wise. Not bleeding edge..
 2. Pease make it a relatively smooth transition for plugin developers.
    I still got scars on my back from the QGIS 2--> 3 transition
 3. I like the idea, that you can build QGIS with both the QT ver 5.x
    and QT ver 6.x in a (limited) time period. That gives the plugin
    developer some peace of mind, having both the "old" and the "new"
    QGIS as a testing ground before plugin release

Tom Lehrer - Be prepared: https://www.youtube.com/watch?v=gkrheaWuShU

-- 
Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 06-07-2020 kl. 00:44 skrev Nyall Dawson:
> 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-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200706/562497e5/attachment-0001.html>