On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote: > While I'd rather sooner than later see us switch to C++20, ever since > 5.7, we have dropped supported compilers only after an LTS release (5.6, > in that case).
We are after an LTS release (6.5). We could have done this for 6.6 and had the same ages for the compilers as 6.0 did, but it's too soon. So 6.7 sounds good. > Since I agree the train for 6.6 has left the station, as Integrity (and > possibly QNX?) don't have an official C++20 offering, yet > (https://ghs.com/products/compiler.html, IIRC, they're going to release > one this year, but I don't know what features they're shooting for), I > was assuming that 6.9 would be the next option. I personally think that a March 2025 release is late. I'd like to pull that in. But since I don't think the 6.8 release will be acceptable, we get only the March 2024 release as another option. > Personally, I would support a break after 6.8. That's scheduled for > release in summer/autumn 2024, and has three years LTS, so gives > affected customers until autumn 2027 to update their tool-chains. By > that time, C++26 will be out already. Qt 6.5 was released March 2023. If it's supported for 3 years for those customers, they have until March 2026 to upgrade. Is that so bad? (Honest question) > Even that, within TQtC, is seen as too early by some. After all, we > still support 5.15 and therefore C++11, in 2023. That's only because > 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a > VLTS release, too, if sufficient numbers of customer won't be able to > upgrade to C++20 by 2027. If you're only going to make a VLTS release every 4.5 years, then we won't be able to adopt every C++ release. C++23 may be too soon for adoption in late 2024 (release March 2025), but we may then skip C++26 for the one after. > From a maintenance POV, it should be easier to support a C++17-based > VLTS release than one that's still stuck on C++11 (and doesn't actually > test for compatibility with that version in the CI...). Sorry, I can't help you there (literally). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development