If you still haven't upgraded from a version released 13 years ago to one released 9 years ago, what difference does a slightly faster release tempo make? If it's that much work, something else has gone wrong in the software development process and all the Python upgrades are doing is making that failure harder to ignore.

Then this is an unfair critique of this new release process. If you had issues with breaking changes between minor 3.x versions, then I'd fully understand.

Are complaints about things breaking between 2.x versions somehow invalid? It’s the same steering group that has made a series of breaking changes. Even people on branches of this thread claim there are breaking changes in 3.7 > 3.8. I’m not sure I would willingly use python for any new project unless necessary, putting it into the same bin as national instruments.

It's a valid complaint on it's own, sure. But it kind of looks like you're complaining that they're going from an ~18 month cycle to a scheduled 12 month cycle. It's not really valid as a complain for this particular change. You're talking about a decade. 18 months vs 12 months seems inconsequential for you.

I'm complaining about the ethos of the python maintainers. I don't see how putting out updates more rapidly will do anything to my complaints other than make future me dislike using python even more. At first I thought they missed a beat but now I think they're playing free jazz.

The 3.x releases _are nothing like_ the 3.0 release. You have a valid complaint about the 3.0 release, which was 11 years ago. If you've not tried updating from 3.x to 3.y — which is a very different process — then you have no stake in this change.

It's your call to make. If your system doesn't have some sort of 'security' risk to it, then all the reasons you have to upgrade are purely internal cost-benefit analysis.

Code is a tool, treat it like any other. Just be aware of possible accumulating deferred costs. I don't know exactly what field your in, but just imagine any other piece of equipment or component going EOL, and the manufacturer only providing semi-drop in replacements. Or even if they are advertised as "drop in", you know that half the time they aren't, and something derpy happens on integration.

The system is not firewalled from the internet. There are tools that need internet based licenses. There are organization firewalls, but there is always a risk involved with having unpatched platforms. I have to weigh that risk against the cost of porting. Both are difficult to gauge.

How are the Python 2.5 components being invoked? Are they python processes that are constantly running? Or are they jobs spun up by other processes?

Oh they’re always running and on dozens of machines.