The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect
On what planet is the currently released version of any software "not a live system?"
You are responsible for that, not them. And if Python 3.13 is fine for you and you report a performance regression for 3.14, you can still stay on 3.13. And as you say, it was introduced in a new release. What happens when the other side goes and says “3.14.5 regressed on the GC pause times and my p95 web server latencies went up. Please revert”? At least one side can make the case “performance was changed on a major release of Python boundary” while the other is changing the performance on a minor release boundary. It’s an arbitrary decision that speaks to the politics of the organization and less about a well reasoned technical plan.
I really don’t have words. When people bemoan the state of software engineering, your comment here is exactly what they’re talking about.
You mean software that has to be deployed locally? Like the example I gave?
> you'd know the world of difference
It's actually worse. The longer you take to get a fixed version out there, the more people will install the buggy version. As distribution is more difficult than just merging a Github PR, that buggy version will live longer on live systems. And before you say "but it's on the developer/DevOps/sysadmin to test," I point you to the countless CVEs where this didn't happen.
Knowing this is the situation, it's unconscionable to leave a faulty build on live for longer than necessary, when you can rollback the change with limited risk.
As for Windows, I think you need a better example. OSes frequently change their performance profile on certain workloads and use more memory. Terrible example.
Also please cool it with the personal insults. They’re not productive and shows you’re trying to win the argument through force and emotion instead of reason.