[Development] Deciding on EOL for Visual Studio 2022

[Thiago Macieira]

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20251201/338edac2/attachment.bin>