Thanks for the quick confirmation Jürgen!
On 14 February 2018 at 19:07, Jürgen E. Fischer <j...@norbit.de> wrote:
>> If this is the case, it means that upgrading our qt version at some stage to
>> 5.9.4 (or 5.10.1) would also affect patch releases, right? E.g. updating to
>> 5.10.1 for a future 3.2 release would mean that the next 3.0.x build would
>> also jump up to 5.10.1.
> As 3.0 will be replaced with 3.2 once it's there (3.4 will be the next LTR),
> that's not the actual case. But yes, switching to a newer version for Qt5
> require to rebuild everything that uses Qt5 (currently that's - not counting
> PyQt5 - only QGIS 3.x).
But what about dev releases? E.g. if we wanted to introduce 5.10 for
3.2 on Windows, then switching over the dev builds alone isn't
possible, right? We'd have to update the Qt library for all builds
(3.0.1 and above) and the dev builds simultaneously. I guess we could
theoretically time an upgrade to occur just before a stable release
(i.e. right before 3.2.0, when no more 3.0.x builds will be released),
but that sounds potentially dangerous.
>> So I'd hate to see the Windows builds locked to 5.9 indefinitely.
> Windows is not the only platform. Debian unstable is also at 5.9 currently,
> buster/testing 5.9, stretch/stable has 5.7 (so we build without 3D there).
> bionic (next ubuntu lts) also has 5.9.
Oh yeah, linux distros are a totally different matter and I'm not
suggesting any change there. I'm just curious about what the exact
situation is with the Windows builds.
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer