<div dir="ltr"><br><br>On Tue, 17 Dec 2024 at 23:56, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> I also believe verisonning Qt6 QGIS builds as 4.0 is the right thing to<br>> do for clarity and from a semantic versioning point of view. This is a<br>> major API break from plugin perspective.  We don't necessarily need to<br>> deal with removal of deprecated APIs at that time . That can be<br>> postponed for a QGIS 5.0. Version numbers are cheap ;-)<div><br></div><div>While I agree that it's probably correct in theory, my problem with this is that if we bump to 4.0 now then we've burnt our version break chance for the next ~5 years or so. This is from a social (not technical) point of view -- we can't be seen breaking API frequently or it erodes trust in QGIS' long term stability.</div><div><br></div><div>And I'm looking at the recent release of Qt 6.9 beta, and honestly wondering how long it'll be before Qt 7! Qt 4 only reached 4.8, Qt 5 reached 5.15... it's not unreasonable to guess that we may already be past the half-way mark before Qt 7 is a thing. 🤣</div><div><br></div><div>So that's why I keep leaning toward NOT bumping the version now, and holding that card back till we REALLY need it (say in 2-3 years, when the hassle of dragging around deprecated QGIS API is infeasible and we need to move to Qt 7 or we want to move to GIL-less python or ???).</div><div><br></div><div>Nyall</div><div><br></div><div><br>><br>> Related to that debate, years ago I wanted to call GDAL 2.5 what has<br>> finally been released as GDAL 3.0. From a GDAL perspective, the only<br>> difference between 2.4 and 2.5/3.0 was the PROJ 6 dependency and the<br>> mundane change that CRS were now authority axis aware by default. I<br>> don't regret the 2->3 bump because it turned to be a major change for<br>> users, and the bump was a clear sign they had to do something.<br>><br>> Le 17/12/2024 à 09:17, Nyall Dawson via QGIS-Developer a écrit :<br>> > On Tue, 17 Dec 2024 at 18:00, Julien Cabieces<br>> > <<a href="mailto:julien.cabieces@oslandia.com">julien.cabieces@oslandia.com</a>> wrote:<br>> >><br>> >> Hi,<br>> >><br>> >> I'm also in favor of switching to Qt 6 builds and the timeline you<br>> >> propose Martin seems reasonnable to me.<br>> >><br>> >> However, I think we should increment the QGIS major version to 4.0 in order<br>> >> to stongly advertise our users and plugin developers that there is an<br>> >> API break. If we are not doing now, when do we plan to increment the<br>> >> major and clean the code from all deprecated content?<br>> > I'm SO strongly against breaking QGIS API unless we ABSOLUTELY have<br>> > to. The pain of the 3.0 transition is still relatively fresh in my<br>> > memory, and I think we would be doing our users and end user<br>> > organisations a great disservice by moving to QGIS 4.0 now.<br>> ><br>> > I think a 4.0 API bump should be an absolute last resort, when we have<br>> > no other option.<br>> ><br>> >> Regarding the proposal of having 2 versions (Qt 5 and Qt 6), I'm not<br>> >> completely sure this is a good idea. I'm afraid that plugin developer<br>> >> would delay the plugin migration if this is still possible to run a QGIS<br>> >> with Qt 5.<br>> > Well, that's entirely their choice. But I'd imagine end user pressure<br>> > would result in the majority of frequently used plugins being upgraded<br>> > quite quickly. And if a particular plugin ISN'T compatible with the QT<br>> > 6 builds, then the user who requires that plugin could still run the<br>> > Qt 5 build for the foreseeable future.<br>> ><br>> >>   It would also be<br>> >> interesting to display on the plugins platform which are compatible with<br>> >> Qt 6 and which are not.<br>> > Definitely -- that would help users make informed decisions as to<br>> > which is the best choice for them.<br>> ><br>> > Nyall<br>> ><br>> >> Regards,<br>> >> Julien<br>> >><br>> >><br>> >><br>> >>> On Tue, 17 Dec 2024 at 10:48, Greg Troxel via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> wrote:<br>> >>><br>> >>>> I wonder about "less stable" qt5 and "more stable" qt6.  Do we really<br>> >>>> believe that qgis built on qt6, with no plugins will have fewer crashes<br>> >>>> and quirks, than the qt5 build?<br>> >>> 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<br>> >>> 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<br>> >>> 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<br>> >>> on Qt 6. This gap is only getting wider as newer operating system updates and corresponding changes break things underneath Qt 5.<br>> >>><br>> >>> 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.<br>> >>><br>> >>>>   That is surprising to me at this point.<br>> >>>> Do we still believe that if one assumes "qgis with N random plugins that<br>> >>>> claim to support qt6"?<br>> >>> (Well, QGIS + **ANY** plugin = a less stable QGIS. 🤣 But that's a completely different point)<br>> >>><br>> >>>> I expect a qt6 build is kind of like a .0 release, and we would want to<br>> >>>> have qt6 builds widel avaialable and time for feedback before saying<br>> >>>> it's stable.<br>> >>> 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<br>> >>> 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)<br>> >>> October 2025 milestone that we'll have a very stable Qt 6 build available.<br>> >>><br>> >>> Nyall<br>> >>><br>> >>>> _______________________________________________<br>> >>>> QGIS-Developer mailing list<br>> >>>> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>> >>>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> >>>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> >>> _______________________________________________<br>> >>> QGIS-Developer mailing list<br>> >>> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>> >>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> >>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> >> --<br>> >><br>> >> Julien Cabieces<br>> >> Senior Developer at Oslandia<br>> >> <a href="mailto:julien.cabieces@oslandia.com">julien.cabieces@oslandia.com</a><br>> > _______________________________________________<br>> > QGIS-Developer mailing list<br>> > <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>><br>> --<br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a><br>> My software is free, but my time generally not.<br>> Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.<br>><br></div></div>