<div dir="ltr">Hi,<div><br></div><div>A fixed date for releasing QGIS with Qt6 sounds like a good idea. And October 2025 sounds like a good timeline.</div><div><br></div><div>We already have a Qt6 version for Windows and the one for macOS should not be too far off.</div><div><br></div><div>I am wondering if we are doing ourselves a favor if we continue to provide Qt5 builds after the shift.</div><div>Wouldn't this prevent us from using pure Qt6 API's and bind development effort for backwards compatibility?</div><div><br></div><div>Alternatively we could extend the lifetime of 3.40 for some more time (until October 2026 or even February 2027) and only then release the next LTR.</div><div>This would reduce the pressure to migrate immediately and I also wonder if we want the first ever official Qt6 build to directly become LTR.</div><div><br></div><div>Cheers</div><div>Matthias</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 17, 2024 at 1:47 PM Julien Cabieces via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> writes:<br>
><br>
>> On Tue, 17 Dec 2024 at 10:48, Greg Troxel via QGIS-Developer <<br>
>> <a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">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>
>><br>
>> Yes, I do. Because Qt 5 is not improving any more, but Qt 6 is. An example<br>
>> would be when running under Wayland environments on linux -- it's a very<br>
>> broken mess on Qt 5 and will never be fixed. On Qt 6 it's only a<br>
>> slightly-broken mess, and will likely be non-broken within the next 12<br>
>> months. There's a similar situation for apple processors, which never had<br>
>> full official support on Qt 5 but ARE fully supported on Qt 6. This gap is<br>
>> only getting wider as newer operating system updates and corresponding<br>
>> changes break things underneath Qt 5.<br>
><br>
>> There's also a limited stream of bug fixes getting ported back to Qt 5.15,<br>
>> vs those flowing into the supported Qt 6 releases.<br>
><br>
> That's a good argument.  I have not really dealt with qt6 yet, and my<br>
> impression has been that qt5 is quite stable on my platform (which never<br>
> had any official support).  But upstream's maintenenance policies are<br>
> troubling.<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>
>><br>
>> (Well, QGIS + **ANY** plugin = a less stable QGIS. 🤣 But that's a<br>
>> completely different point)<br>
><br>
> of course.  I just meant that stability(qgis-only) could have a<br>
> different answer than stability(qgis+p1+p7), where p7 not working with<br>
> qt6 leads to a 0 score on the stability metric.<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>
>><br>
>> I'd say we're well past the ".0" stage of Qt 6 support. Almost all the core<br>
>> functionality is quite well tested at this stage, and third party clients<br>
>> (like Mergin and QField) switched to Qt 6 based QGIS builds earlier this<br>
>> year. I'm confident that by the time we hit a (potential) October 2025<br>
>> milestone that we'll have a very stable Qt 6 build available.<br>
><br>
> My experience (not in qgis) is that broad releases often uncover<br>
> problems not hit by testing with less scope.  Maybe there won't be much<br>
> or perhaps even any, but until the broader qgis world, on varying<br>
> systems.<br>
><br>
> Therefore I think it would be good to start offering qt6 builds on the<br>
> website before then, at least by July, to let a larger pool of users try<br>
> them, marked "for testing" and then the labels can flip to "for use with<br>
> old plugins"/"recommended".<br>
><br>
<br>
Agreed, If we were to propose the 2 versions (Qt5 and Qt6) side by side,<br>
we should propose the Qt 6 version for download sooner than october. Why not 3.42 in february?<br>
<br>
<br>
><br>
> I will see about making the pkgsrc package have an option for which qt<br>
> flavor, so I can test too.<br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
-- <br>
<br>
Julien Cabieces<br>
Senior Developer at Oslandia<br>
<a href="mailto:julien.cabieces@oslandia.com" target="_blank">julien.cabieces@oslandia.com</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>