3 ms·
> State 5. Never change anything or do any useless activities or upgrades unless you really have no other choice and there's clear demonstrated value in the cha
by perlgeek 10y ago
> State 5. Never change anything or do any useless activities or upgrades unless you really have no other choice and there's clear demonstrated value in the change.
State 6. Realize that painful steps need to be automated and repeated often. Then each upgrade has much fewer changes, and it's easier to locate the source of errors.
- vacri 10y agoI'll second this. At one of the places I currently work at, we have the same codebase split between nodejs 0.10.40 and node 6.2.something, because the devs were scared of the incremental changes and having to fix small things along the way. It's a nightmare now, and transitioning the final stuff off is proving to be a massive wallop of tech debt. If you have a team that's actively working on the code, incremental upgrades to the dependencies should be pretty comfortable. But if you've got some legacy thing that no-one really knows, then is the time to start being careful about updating little bits.
- coredog64 10y agoI once worked with a CIO that had a policy that we should be no more than one version behind current on software. The idea was that most vendors will have an easy migration plan to current, but beyond that you usually had to upgrade twice with all the attendant pain. It's not fun, but as a consequence you don't get stuck with something that you absolutely can't maintain.