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.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
