Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Marlo I'm guessing you are thinking about environment/OS upgrades? When it comes to your actual codebase you update libraries etc on your working copy and into source control and then release these like any other bug fix/ feature update, it would be the same as any other release.
-
@ALivingMemory
In my opinion, it applies to languages, libraries, AND operating systems.
A good production application infrastructure should always be redundant, which means a minimum of two servers — which means you can install a new operating system, test it, add it to the pool of servers, and take an old one away.
The only reason for down time is when your load balancer needs to be worked on 😜 -
@bittersweet Agreed. Avoiding downtime is no excuse for refusing to keep your tools up to date. If it is that much of a problem then you should have already configured an infrastructure that supports big upgrades with no downtime. It's laziness and general stubbornness that gets in the way.
"Older versions are more stable"
The whole concept of LTS in development pisses me off.
Delayed upgrading, whether it's the language itself, dependencies or tooling, does just one thing: It makes future upgrading way more difficult, often to the point where the company eventually runs into this maintainability wall, and gets stuck in old, unsupported versions.
"But... stability!" — The tiny chance that the newer version has such serious stability regressions that it negatively impacts your own product doesn't weigh up against the clusterfuck you fall into if you push the task too far into the future.
You can relatively easily assess a new major language version using benchmarks and unit tests. Predicting the repercussions of staying on PHP 5.4 or Python 2.7 for another year, predicting the impact of upgrading the codebase later, that is almost impossible.
I'm not saying you should live on the bleeding edge in production, but as soon as a new stable version of a core technology is released, just fucking drop everything you're doing and port those deprecated methods!
undefined
wk66