[stevepike]

(Good project management is the key to this work. You need to spend the time up front (scripts can help here, but the tooling isn't awesome) to figure out everything that's going to block your language upgrade. For all those blockers you want to work as hard as you can to find backwards-compatible fixes (like upgrading a blocking dependency to a version that's dual-compatible with your current and next language version). Then you work through small incremental PRs so your eventual large upgrade is easier. This also works for code changes around breaking changes - often you can make these changes ahead of time, standalone. I've done individual rails minor version upgrades that took 100 PRs of pre-work.

In my experience often developers try to take a shortcut where they try to bang out the large upgrade in one giant PR. Sometimes this works but it's very risky - more often I see very long running branches that get abandoned. It's much better to make guaranteed incremental progress, plus your PRs are much easier for your team to review.

My startup Infield solves this problem for python / ruby / JS backends through software for the project planning (we run a solver over your dependency graph and read every changelog to identify breaking changes) and people for the breaking changes (our team will open PRs where we fix breaking changes so your code is compatible). We're starting to think about moving into the statically typed backend world with java / .net / maybe scala. I'd love to hear more about exactly what you've run into and whether my experience here matches with these ecosystems.