[Development] Deciding on EOL for Visual Studio 2022
Volker Hilsheimer
volker.hilsheimer at qt.io
Mon Dec 1 22:21:22 CET 2025
> On 1 Dec 2025, at 21:57, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Monday, 1 December 2025 11:51:31 Pacific Standard Time Scott Bloom wrote:
>>> Anyway, I think the proposal I made for VS2026 still makes sense for the
>>> Qt Project:
>>> * 2026-2027: toolchains 14.44 (VS2022), 14.50, sliding 14.51-53
>>> * 2028-2029: toolchains 14.50, 14.54, sliding 14.55-57
>>> * 2029-2030: toolchains 14.54, 14.58, sliding 14.59-61
>>>
>>> This would mean Qt 6.12 still supports VS2022, but Qt 6.16 (Oct 2028) does
>>> not.
>>
>> --
>> Just my 2 bits from a user POV.
>>
>> Please allow 18 to 24 months before you REQUIRE 2026 for building a Qt
>> project. Meaning any new C++ features that 2026 has that 2022's latest
>> patch does not support be held off in use in the public API for up to two
>> years after the release of 2026.
>
> From the plan above, VS2026 won't be required until 2028, specifically starting
> with Qt 6.15. That's over 24 months from today.
>
> But I agree on sufficient notice, which means we should make this decision in
> time for the Qt 6.11 release announcement.
>
> It's a different story to about adding content to our headers that requires
> VS2026. At that point, it won't be about just Visual C++. It's highly unlikely
> the compilers holding us back now will have been updated in 24 months time.
>
> But I repeat we should add new, optional features that depend on C++20 or even
> 23. People who won't upgrade simply will have to settle for doing things the
> way they're doing them today. I personally do not plan on writing any non-
> concept code for any new template function.
The decision so far is to not require post-17 C++ functionality until the usage of those brings substantial benefits to _users_ of Qt.
The most up-to-date information we have from users, customers, and from some of the compiler developers we work with and that keep track of this kind of thing, indicate that C++20 is not at all mainstream in the real world. I don’t know if things have moved significantly, it’s been a few years.
Yes, for optional features, like providing convenience overloads, using C++20 or 23 is fine. For primary features it is not.
Volker
More information about the Development
mailing list