I also believe verisonning Qt6 QGIS builds as 4.0 is the right thing to
do for clarity and from a semantic versioning point of view. This is a
major API break from plugin perspective. We don't necessarily need to
deal with removal of deprecated APIs at that time . That can be
postponed for a QGIS 5.0. Version numbers are cheap ;-)
Related to that debate, years ago I wanted to call GDAL 2.5 what has
finally been released as GDAL 3.0. From a GDAL perspective, the only
difference between 2.4 and 2.5/3.0 was the PROJ 6 dependency and the
mundane change that CRS were now authority axis aware by default. I
don't regret the 2->3 bump because it turned to be a major change for
users, and the bump was a clear sign they had to do something.
Le 17/12/2024 à 09:17, Nyall Dawson via QGIS-Developer a écrit :
On Tue, 17 Dec 2024 at 18:00, Julien Cabieces
<julien.cabie...@oslandia.com> wrote:
Hi,
I'm also in favor of switching to Qt 6 builds and the timeline you
propose Martin seems reasonnable to me.
However, I think we should increment the QGIS major version to 4.0 in order
to stongly advertise our users and plugin developers that there is an
API break. If we are not doing now, when do we plan to increment the
major and clean the code from all deprecated content?
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.
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.
It would also be
interesting to display on the plugins platform which are compatible with
Qt 6 and which are not.
Definitely -- that would help users make informed decisions as to
which is the best choice for them.
Nyall
Regards,
Julien
On Tue, 17 Dec 2024 at 10:48, Greg Troxel via QGIS-Developer
<qgis-developer@lists.osgeo.org> wrote:
I wonder about "less stable" qt5 and "more stable" qt6. Do we really
believe that qgis built on qt6, with no plugins will have fewer crashes
and quirks, than the qt5 build?
Yes, I do. Because Qt 5 is not improving any more, but Qt 6 is. An example
would be when running under Wayland environments on
linux -- it's a very broken mess on Qt 5 and will never be fixed. On Qt 6 it's
only a slightly-broken mess, and will likely be non-broken within
the next 12 months. There's a similar situation for apple processors, which
never had full official support on Qt 5 but ARE fully supported
on Qt 6. This gap is only getting wider as newer operating system updates and
corresponding changes break things underneath Qt 5.
There's also a limited stream of bug fixes getting ported back to Qt 5.15, vs
those flowing into the supported Qt 6 releases.
That is surprising to me at this point.
Do we still believe that if one assumes "qgis with N random plugins that
claim to support qt6"?
(Well, QGIS + **ANY** plugin = a less stable QGIS. 🤣 But that's a completely
different point)
I expect a qt6 build is kind of like a .0 release, and we would want to
have qt6 builds widel avaialable and time for feedback before saying
it's stable.
I'd say we're well past the ".0" stage of Qt 6 support. Almost all the core
functionality is quite well tested at this stage, and third party
clients (like Mergin and QField) switched to Qt 6 based QGIS builds earlier
this year. I'm confident that by the time we hit a (potential)
October 2025 milestone that we'll have a very stable Qt 6 build available.
Nyall
_______________________________________________
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
_______________________________________________
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
--
Julien Cabieces
Senior Developer at Oslandia
julien.cabie...@oslandia.com
_______________________________________________
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
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
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
