You could argue that 2.y is also a different language than 2.x but this is besides the point: as long as there is a compiler for that language and it works (for your definition of works) you don't need to translate your programs in another language just because you have money.
You don't need to upgrade your servers to the lastest linux kernel either. But in 10 years, you won't get any security update for it, unless you pay a lot of money for it.
It will be the same for Python.
You want the excellent and money making free work of volunteers ? Do your part.
You don't want too ? It's ok. In 2020, plenty of companies will sale you services for the real market price of your technical debt.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions?
I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
Companies who cannot upgrade their codebases are companies who cannot maintain their codebases.
Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will.
(small and non-notable exceptions for the literal handful of types of orgs where this is not the case)
True, but is there a situation where upgrading will hurt instead of benefit?
Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme.
For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, they simply have different opinions on what is valuable than you do.
Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time.
But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features. Nobody in their right mind thinks you can have a company with zero technical debt, there's always a balancing act in play, but if your managers are just playing the risk card without, you know, doing an actual risk analysis which includes the risk of not being able to deliver future features, then your company isn't making smart decisions.
Now, there do exist codebases where you can make the logical conclusion that there really will not be any future feature work, but it's still running in production and so it will need support, and it's a fairly large codebase, and so there would be an enormous cost to re-certifying for the upgrade with very little apparent benefit. That happens, but it only (really, truly, only) happens in large enterprises with many, large codebases and only so many engineers. Those enterprises do have the resources to hire new employees and/or outside contractors to pay down the technical debt on these half-alive projects - they just aren't prioritizing those resources on the technical debt, even long after it became clear that the clock couldn't be stretched out any longer. Through painful personal experiences, I have zero sympathy for companies in that position who think that they can solve their problems with more firewalls.
There is cost the individual user of an open source project has to consider, and there is cost the community of that project as a whole has to consider.
So from your perspective, just keeping the old version might be "the right thing to do", and at the same time the decision of the community to not support it anymore is also "the right thing to do" from their perspective.
As the community does their work unpaid, it seems you have no right to impose your perspective on them, except if you pay money for the necessary work. Which you are free to do.
I guess what the parent posters point out is that this will usually shift your own cost/benefit ratio in a way that upgrading becomes "the right thing to do" for you, too.
I don't think that centos 6 is bug free yet it EOL in 2010 too.
Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox.
My client won't upgrade. They pay support, expensive support, to keep their old version.
In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't migrate.
Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work is extremely unfashionable.
It's not the opensource movement. It's IT in general. A lot of software stopped working with the windows 10 update that was forced on the users.
Android breaks the API regularly by changing the permission game.
The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.
Actually, Android doesn't break the API, even by changing the definition of permissions. If you have a breakage, investigate your app manifest, what API version you are targeting. Android frameworks shim the old behaviors for the apps that declare the use of the old API versions.
E.G: Since API Level 19, the Alarm system has been completely remade. One must check the API Level to act some how or some differently. The same is for permissions after the advent of Android OS 6.0+. But we still need the support library to give Fragments and the ActionBar to API Levels lower than 11. And VectorDrawables to API Levels lower than 23. And many more objects.
The shims are managed by targetSdkVersion, i.e. if you declare targetSdkVersion >= 23, you will get the new permission system (because it was introduced in 23) if running on [23,maxSdkVersion] device; if it is running on device that has API level [minSdkVersion,23), you get the old one; if you declare it < 23, you will get the old one, always, on newer devices too.
The targetSdkVersion says what you designed against. If you claim supporting the new API, you should handle the new API (and that includes detecting what the underlying device supports). That does not preclude you from including the support library needed for lower API levels still supported.
Except if you release a new/updated app, it MUST target a recent (less than a year) targetSdkVersion.
"2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher."
That's Play Store policy for new apps and app updates, not a technical limitation of the OS. Old apps will keep working just like they did before, the new APIs will not break them.
the old trick is to get your changes to the main branch so you dont need to maintain your it. that is also why anyone bothers to do so in the first place
You could argue that 2.y is also a different language than 2.x but this is besides the point: as long as there is a compiler for that language and it works (for your definition of works) you don't need to translate your programs in another language just because you have money.