The Rails upgrade process can be tricky. When using the rails app:update command, a line will be added to load_defaults corresponding to the previous Rails version. For example if you're upgrading to 6.1, it'll be load_defaults(6.0).
The aim of this is to allow for an incremental upgrade process, so you can gradually address the items in config/initializers/new_framework_defaults.rb, then delete that file, and change load_defaults to match the current Rails version.
The risk is that if you don't fully complete that process, your app may work fine, but you'll drift further and further from the default configuration of a new Rails app. This makes future upgrades more difficult.
I think it's easy to overlook this, and it would be useful to have a cop to highlight this. I'm imagining that a typical Rails upgrade would happen on a branch, and while in progress this cop would raise an issue. Then when the upgrade is complete, and load_defaults is updated, it would pass again.
The Rails upgrade process can be tricky. When using the
rails app:updatecommand, a line will be added toload_defaultscorresponding to the previous Rails version. For example if you're upgrading to 6.1, it'll beload_defaults(6.0).The aim of this is to allow for an incremental upgrade process, so you can gradually address the items in
config/initializers/new_framework_defaults.rb, then delete that file, and changeload_defaultsto match the current Rails version.The risk is that if you don't fully complete that process, your app may work fine, but you'll drift further and further from the default configuration of a new Rails app. This makes future upgrades more difficult.
I think it's easy to overlook this, and it would be useful to have a cop to highlight this. I'm imagining that a typical Rails upgrade would happen on a branch, and while in progress this cop would raise an issue. Then when the upgrade is complete, and
load_defaultsis updated, it would pass again.