<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>From a plugin developer's viewpoint:</p>
<ol>
<li>It's basically a good idea to keep supporting libraries (like
qt) up-to-date version wise. Not bleeding edge.. <br>
</li>
<li>Pease make it a relatively smooth transition for plugin
developers. I still got scars on my back from the QGIS 2--> 3
transition</li>
<li>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</li>
</ol>
<p>Tom Lehrer - Be prepared:
<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=gkrheaWuShU">https://www.youtube.com/watch?v=gkrheaWuShU</a></p>
<pre class="moz-signature" cols="72">--
Med venlig hilsen / Kind regards
Bo Victor Thomsen</pre>
<div class="moz-cite-prefix">Den 06-07-2020 kl. 00:44 skrev Nyall
Dawson:<br>
</div>
<blockquote type="cite"
cite="mid:CAB28AsiHPfz1Lp6n14VwaQVdRucKdaJ6AdrY7CSwNS-iq6Y+4Q@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>