On Wednesday, 25 January 2023 08:33:59 PST Michael Jackson wrote: > Like someone else said, it becomes inertia. Our tools work on a daily basis > and any interruption to those tools becomes a productivity issue. Small > productivity losses I can handle, losing multiple days to an "upgrade" just > isn't on my list of things to do.
I understand. In my $DAYJOB at Intel, the product I work on stayed on GCC 10 for way too long, for many reasons, including in particular the fact that there are builds of that for CentOS 7, but not later versions. When it came time to upgrade to GCC 12, it wasn't just an update; we had to redevelop the entire way we create the containers that are used to build the software. Of course, now once burned thrice shy, I've since upgraded the compiler several times by simply modifying a line a Dockerfile. > I feel like dropping VS2017 support is a no-brainer. Dropping macOS Catalina > support is also a no brainer. Not sure about VS2019 as according to > https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019 the > support will end in 2024 and has extended support until 2029. And that is > assuming VS 2019 16.11 and nothing earlier. VS2017 is already gone. The reason I asked about VS2019, aside from the simple learning of many things I did not anticipate, is that we're seeing it have C++ compliance issues. This is not even C++20 or 17; it's a plain constexpr function that should have worked with C++14. Given the answers so far, we can probably get away with dropping it for 6.6. Otherwise, I'll just implement "if VS2017, use slow code". After all, if you wanted performance, you wouldn't be using VS in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
