> On 14 Mar 2025, at 08:22, Schmertmann, Lars via Development > <development@qt-project.org> wrote: > > Hello together, > > sadly we need to support Windows Server 2016 for a while in our > application (https://github.com/Governikus/AusweisApp) because the > extended support of Microsoft is given until Jan 12, 2027. > https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2016 > > While this was no problem in the past, Qt 6.8.0 introduced some changes > that let Qt stop working on Windows Server 2016. > > There is a change that solves the issues (at least on a documentation > level): https://codereview.qt-project.org/c/qt/qtbase/+/629255 > With this mail I would like to ensure all people who could decide about > this change are aware of this change.
Hi Lars, Thanks for the heads-up! We have historically accepted patches that add support for platforms or toolchains that we don’t cover in our CI system, and don’t officially support. The only general requirement I have for such patches is that they don’t break supported platforms, and don’t add (a substantial amount of) complexity to otherwise cross-platform code. Beyond that, it’s for the respective module’s maintainer to decide whether they accept those patches or not. As a general rule, patches should be atomic, so looking at https://codereview.qt-project.org/c/qt/qtbase/+/629255, splitting this in two would be an improvement. > I would really appreciate it when the last public (source) release of > Qt 6.8 (6.8.3) would contain the changes at least in an inactive code > block as a documentation. Qt 6.8.3 has already been branched off and is about to be packaged. I’m very doubtful that our release team will accept patches at this point to support that are not addressing a release blocker. Given that you probably have to build Qt for Windows yourself to set e.g. QT_WIN_SERVER_2016_COMPAT to activate those patches anyway, the question is of course whether maintaining and rebasing those few commits on top of a local clone of the Qt repos (or in a source-controlled copy of the source packages that are part of each Qt release) isn’t more sensible. The code won’t be tested by us, and there’s a non-zero chance that someone at some point will forget this email thread and remove dead code. And of course, new changes that don’t work on that particular Windows version will be introduced sooner or later. > Or is it an realistic idea to question the support of Windows Server > 2016 in general? > > Mit freundlichen Grüßen / Sincerely yours > Lars Schmertmann In our CI, we don’t cover any Windows Server versions. I’m not a product manager, but I doubt that there’s a strong enough business case for those platforms in general, and for an EOL’ed version in particular. But I’m sure that someone from our sales team would be open for a conversation. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
