It can be "very, very old" in its context. If a new release comes out every year, support duration is 5 years and you're 2 years past EOL, I'd agree that the software can be called "very, very old".
And that's where things go off the rails. A release that is only supported for five years is a hobby project.
The kind of software projects that make the world go round continue past the lives of their original authors and can easily span decades. 5 years is just enough for the original shake-out.
I mean i am sure we would do that if any of the user company would want to pay the price for that. None of them want. You probably multiply the price by at least 10 (i would say add at least +1.5 to the multiplier for every year of support and that is probably highly conservative).
Totally agreed, but check upthread for a comment that literally says this tool is unsuitable for work where lives depend on it. And for telcos that's pretty much a given.
Yes, ok, thanks, the Python foundation will immediately spend a lot of time and money to support releases for 2 decades. How could they not know!? /s
That out of the way, you're right that some niches require a lot longer cycles, but it's the big big biiiig advantage of FOSS. Downstream can maintain it for as long as they wish. As you said things got shaken out by the community for free basically, and if some serious software is so so serious that upgrading and retesting/certifying is somehow more expensive than trying to airgap an EOLed pile of libs (while at the same time it needs support) then the stakeholders can do it.
No sarcasm needed, Red Hat happily invests time and money in supporting it until 2024.
That might have been an easy eay to provide upstream releases too, had the Python maintainers not been intent on using deprecations as an instrument to get the community moving.
That strategy doesn't work very well however, as we've seen when TLS 1.2 was held off from Python 2.
> A release that is only supported for five years is a hobby project.
I believe what you are trying to say is that you chose the wrong tool for the job. It is really condescending to lash out on other projects like that just because they don't share the same needs as you. They owe you nothing. Python is free and open source, just fork the damn language spec and support it yourself.
The discussion is about a specific version of ArcGIS that only supports a version of python that reached its end of life, so I beg to differ. My point stands: if you had the need for a really long supported tech, in the order of decades, choosing a tech based on a dependency that had a clear life span of 5 years or so was a poor choice. If, still, you need that, you can support it yourself, by forking your own version, but python owes ArcGIS nothing.
The kind of software projects that make the world go round continue past the lives of their original authors and can easily span decades. 5 years is just enough for the original shake-out.