On 03.05.23 18:24, Thiago Macieira wrote: > 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.
We couldn't've done this for 6.6, because Integrity isn't there, yet. >> 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. [Sorry, yes, 6.9 is in spring '25. I messed up the counting] >> 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) I'm not the one talking to these customers, but the feedback I get from those who do is that yes, it's too early. Then again, the internal plan calls for requiring C++20 for building (but not using) Qt 6.9. I don't see how that helps any user. If they can build Qt in C++20 (or arrange for it to be built for them), then they can build their own project in C++20, too. I get the desire to insulate users from having to port their own code to C++20, but as I said, I don't see how that's possible to avoid if Qt itself must be built with C++20. Maybe TQtC needs to open the VLTS branches up a bit more, to allow a bit more risky kinds of backports than currently, to appease users stuck on these versions due to toolchain issues, but from a Qt OSS project POV, I don't think it's something we need to care about. That is what customers pay money for to TQtC, so it's TQtC's decision how to deal with this. >> 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. C++20 (like C++11) are a bit special as they're rather large releases. Companies and customers may be (rightfully) more reluctant to upgrade to C++20 than they were from, say, 11 to 14, which is what I expect 20-23 to feel like. Thanks, Marc -- Marc Mutz <marc.m...@qt.io> Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development