[scott_w]

Your argument is, frankly, idiotic. If a version of Windows, or any deployed software, has a performance regression, do you consider it “not a live product” because you didn’t personally install it yet?

I really don’t have words. When people bemoan the state of software engineering, your comment here is exactly what they’re talking about.

[vlovich123]

3.14.5 has a serious performance regression - GC pause times have increased significantly since the entire 3.14 series. This is the problem - you’re arbitrarily putting max RSS of certain workloads over the p95 latency of others. It’s arbitrary and why the worst kind of software engineering that inhibits software progress for the sake of nothing changing.

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.

[Orygin]

Snarky comment aside, Python is definitely *not* a "live system". If you had worked with such system before you'd know the world of difference between a version release of "stable" software versus a live platform that cannot fail.

[scott_w]

> If you had worked with such system before

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.