Upgrade path breaks out the steps involved in a complex upgrade. You can use this information to estimate how much work an upgrade will be and to break the work up across multiple engineers or to mix it into a maintenance rotation.

As the upgrade progresses you can also use Infield to track progress and to review upgrade guides when there are breaking changes.

Blockers

Blockers are other packages you’re required to upgrade in order to achieve your goal. The example above has six packages that need to be upgraded before Rails can be upgraded from 5.2 to 6.0. The first five (group 1) can be upgraded ahead of time in any order. For each of these packages Infield has identified a target version that is compatible with both Rails 5.2 and 6.0. You can upgrade these packages to those target versions ahead of time so that the Rails 5.2→6.0 upgrade is as low risk as possible.

The composite_primary_keys package, on the other hand, has no version that’s compatible with Rails 5.2 and 6.0 simultaneously. This blocker is coupled together with Rails and you’ll need to upgrade them in the same PR.

Breaking changes

Some upgrades require more effort than others. Infield reads the changelog of every package you need to upgrade and shows you the breaking changes you’ll run into. You can view these changes and their remediation steps inside Infield, and record your analysis as you evaluate each one on your codebase.

For example, the responders gem in our example has two breaking changes in the changelog, but neither apply to this codebase (which is on Rails 5.2 and Ruby 2.5). These changes can be marked as “Not applicable”.

📘

Rails itself provides a more comprehensive upgrade guide than most changelogs. Infield displays the upgrade guide inline so you can annotate it as you review your codebase.

As you merge upgrade PRs, your Upgrade Path will update automatically to reflect the remaining steps.