Upgrading From Rails 7.1 to Rails 7.2: A Step-by-Step Guide for Enhancing Your Application

On August 9th, Rails 7.2 was released, bringing a host of new features and improvements to the framework. Ten months ago, I demonstrated how to upgrade a Rails application from 7.0 to 7.1, which was well-received by the community. Today, I will take you through the process of upgrading OneTribe from Rails 7.1 to 7.2. This upgrade not only ensures compatibility with the latest Rails enhancements but also allows me to better understand new Rails functionalities and performance optimizations. Let’s dive into the upgrade process and explore what Rails 7.2 has to offer. Prerequisites OneTribe runs Ruby 3.3.4 and Rails 7.1.3, which is good because Rails 7.2 requires Ruby 3.1.0 or newer. Nothing changed in code hosting and deployment; we still use GitHub and GitHub Actions with Kamal. Dependencies Update The first thing you do to upgrade Rails is to change the version in the Gemfile. # Gemfile # ... gem "rails", "~> 7.2.0" # ... Than you do bundle update rails and either you will be see that everything is fine or you will see that something is wrong. In my case, I got an error that pg_party does not support Rails 7.2 yet. I checked the gem’s repository and saw that there was already a PR with support for Rails 7.2, but it has not yet been merged. I decided to use the code from the PR. # Gemfile # ... gem "pg_party", github: "marcoroth/pg_party", branch: "rails-7.2" # ... gem "rails", "~> 7.2.0" # ... After I fixed the issue, I tried to run specs with ./bin/rspec and got a strange error. An error occurred while loading ./spec/workers/member/next_birthday_worker_spec.rb. Failure/Error: require File.expand_path('../config/environment', __dir__) NameError: undefined method `validate_find_options' for class `# ' # ./config/application.rb:22:in ` ' # ./config/environment.rb:4:in `require_relative' # ./config/environment.rb:4:in ` ' # ./spec/rails_helper.rb:6:in ` ' # ./spec/workers/member/next_birthday_worker_spec.rb:3:in ` ' I ran ./bin/rspec -b to see the backtrace and found that the error was caused by the acts_as_paranoid gem. We used very old version of the gem, so I updated it to the latest version and bundled. I found out that I didn’t migrate the database when I fetched the latest changes from the repository. I ran ./bin/rails db:migrate and got another error. ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection Tasks: TOP => db:schema:dump (See full trace by running task with --trace) To debug this, I again used --backtrace option. ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate --backtrace Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-7.2.0/lib/active_record/schema_dumper.rb:45:in `dump' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:18:in `block (4 levels) in ' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `open' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `block (3 levels) in ' Backtrace helps quickly identify the issue. In my case, it was the hairtrigger gem that was outdated and not compatible with Rails 7.2. Finally, I was able to migrate and run specs successfully with ./bin/rspec. Third-party Deprecations During RSpec run I saw a couple of deprecation warnings and decided to fix them before going further. DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. I don’t use connection directly in the code, so the message was caused by some gem. The problem was that I had no idea which gem caused the warning. How would you handle this? I found out that starting from a Rails 7.1 there is a Rails.application.deprecators API, which can be extremely useful in this case. I updated my config/application.rb file to include the following code: # config/application.rb module OneTribe class Application < Rails::Application # ... deprecators.debug = true if ENV["DEPRECATION_DEBUG"] end end Then I ran the specs with DEPRECATION_DEBUG=true ./bin/rspec and saw the following output: DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. (called from load at ./bin/rspec:27) /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:15:in `block in all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `map' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:36:in `begin_transaction' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all.rb:24:in `block in begin_transaction' Now everything was clear. The warning was caused by the test-prof gem. I decided to ignore it for now and continue with the upgrade. Rails Deprecations Another deprecation warning I saw was: ➜ onetribe git:(rails-7-2) ✗ ./bin/rspec DEPRECATION WARNING: Defining enums with keyword arguments is deprecated and will be removed in Rails 8.0. Positional arguments should be used instead: enum :role, {:employee=>"employee", :manager=>"manager", :administrator=>"administrator"} (called from at /Users/igor/workspace/onetribe/app/models/member.rb:14) In mid-February 2024, there was a PR that deprecated defining enums with keyword arguments. Before it was possible to define enums like this: # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum allocation_type: { general: 0, extra: 1, auto: 2 }, _prefix: :allocation_type end With this change you should define enums like this: # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum :allocation_type, { general: 0, extra: 1, auto: 2 }, prefix: :allocation_type end This new syntax eliminates the need to prefix options with an underscore. For some reason, this change wasn’t mentioned in the Rails 7.2 release notes, but it’s good to know about it. Application Configuration Update Rails has a special task rails app:update that can help you to update application configuration in an interactive mode. I use VS Code for development and wanted to use its merge tool, so as in the previous update, I specified THOR_MERGE constant before running the command THOR_MERGE="code --wait" ./bin/rails app:update and used merge tool (m option) to track changes over files. During the update, I found only one notable configuration change. Annotation of views with filenames is now enabled by default in development. This setting is handled by config.action_view.annotate_rendered_view_with_filenames = true in config/environments/development.rb. Team Schedule With this setting enabled, you will see comments like this in the HTML source of the page. I am not sure if it’s useful, but it’s good to know about it. App Defaults After you merge all the changes, you can run the specs again to make sure everything is fine. Now it is time to make sure that your application is ready to run with Rails default settings, which are applied to every new Rails 7.2 application. This can be done in two steps. In config/initializers there should be a new file named new_framework_defaults_7_2.rb. It includes all Rails 7.2 default params commented, so you can enable them one by one and make sure that your specs are still green and your application is still working. After after, you can change config.load_defaults in config/application.rb file to have 7.2 value and delete new_framework_defaults_7_2.rb. This will enable all options at once. Development Container One new feature of Rails 7.2 that deserves to be mentioned in this text is format support of Docker development containers. Yes, nobody prevented you from using dev container before Rails 7.2, but now you can generate container configuration for new apps with rails new myapp --devcontainer command. This will create a new Rails app with the .devcontainer folder that includes devcontainer.json, Dockerfile and docker-compose.yml files. For applications that were upgrade you can use ./bin/rails devcontainer console command to generate the same files. Conclusions Since 7.2 is a minor release, there are not many changes and new features, however the Release Notes are rather long. I will not cover everything here, but I suggest you read them. Maybe I will write a separate post about some of the new features. Stay tuned! On August 9th, Rails 7.2 was released , bringing a host of new features and improvements to the framework. Ten months ago, I demonstrated how to upgrade a Rails application from 7.0 to 7.1 , which was well-received by the community. Today, I will take you through the process of upgrading OneTribe from Rails 7.1 to 7.2. This upgrade not only ensures compatibility with the latest Rails enhancements but also allows me to better understand new Rails functionalities and performance optimizations. Let’s dive into the upgrade process and explore what Rails 7.2 has to offer. Rails 7.2 was released how to upgrade a Rails application from 7.0 to 7.1 Prerequisites OneTribe runs Ruby 3.3.4 and Rails 7.1.3, which is good because Rails 7.2 requires Ruby 3.1.0 or newer. Nothing changed in code hosting and deployment; we still use GitHub and GitHub Actions with Kamal. Dependencies Update The first thing you do to upgrade Rails is to change the version in the Gemfile. # Gemfile # ... gem "rails", "~> 7.2.0" # ... # Gemfile # ... gem "rails", "~> 7.2.0" # ... Than you do bundle update rails and either you will be see that everything is fine or you will see that something is wrong. In my case, I got an error that pg_party does not support Rails 7.2 yet. I checked the gem’s repository and saw that there was already a PR with support for Rails 7.2, but it has not yet been merged. I decided to use the code from the PR. bundle update rails pg_party gem’s repository # Gemfile # ... gem "pg_party", github: "marcoroth/pg_party", branch: "rails-7.2" # ... gem "rails", "~> 7.2.0" # ... # Gemfile # ... gem "pg_party", github: "marcoroth/pg_party", branch: "rails-7.2" # ... gem "rails", "~> 7.2.0" # ... After I fixed the issue, I tried to run specs with ./bin/rspec and got a strange error. ./bin/rspec An error occurred while loading ./spec/workers/member/next_birthday_worker_spec.rb. Failure/Error: require File.expand_path('../config/environment', __dir__) NameError: undefined method `validate_find_options' for class `# ' # ./config/application.rb:22:in ` ' # ./config/environment.rb:4:in `require_relative' # ./config/environment.rb:4:in ` ' # ./spec/rails_helper.rb:6:in ` ' # ./spec/workers/member/next_birthday_worker_spec.rb:3:in ` ' An error occurred while loading ./spec/workers/member/next_birthday_worker_spec.rb. Failure/Error: require File.expand_path('../config/environment', __dir__) NameError: undefined method `validate_find_options' for class `# ' # ./config/application.rb:22:in ` ' # ./config/environment.rb:4:in `require_relative' # ./config/environment.rb:4:in ` ' # ./spec/rails_helper.rb:6:in ` ' # ./spec/workers/member/next_birthday_worker_spec.rb:3:in ` ' I ran ./bin/rspec -b to see the backtrace and found that the error was caused by the acts_as_paranoid gem. We used very old version of the gem, so I updated it to the latest version and bundled. ./bin/rspec -b acts_as_paranoid I found out that I didn’t migrate the database when I fetched the latest changes from the repository. I ran ./bin/rails db:migrate and got another error. ./bin/rails db:migrate ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection Tasks: TOP => db:schema:dump (See full trace by running task with --trace) ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection Tasks: TOP => db:schema:dump (See full trace by running task with --trace) To debug this, I again used --backtrace option. --backtrace ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate --backtrace Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-7.2.0/lib/active_record/schema_dumper.rb:45:in `dump' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:18:in `block (4 levels) in ' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `open' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `block (3 levels) in ' ➜ onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate --backtrace Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record. bin/rails aborted! NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError) pool.with_connection do |connection| ^^^^^^^^^^^^^^^^ Did you mean? raw_connection /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-7.2.0/lib/active_record/schema_dumper.rb:45:in `dump' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:18:in `block (4 levels) in ' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `open' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `block (3 levels) in ' Backtrace helps quickly identify the issue. In my case, it was the hairtrigger gem that was outdated and not compatible with Rails 7.2. hairtrigger Finally, I was able to migrate and run specs successfully with ./bin/rspec . ./bin/rspec Third-party Deprecations During RSpec run I saw a couple of deprecation warnings and decided to fix them before going further. DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. I don’t use connection directly in the code, so the message was caused by some gem. The problem was that I had no idea which gem caused the warning. How would you handle this? I found out that starting from a Rails 7.1 there is a Rails.application.deprecators API, which can be extremely useful in this case. connection starting from a Rails 7.1 Rails.application.deprecators I updated my config/application.rb file to include the following code: config/application.rb # config/application.rb module OneTribe class Application < Rails::Application # ... deprecators.debug = true if ENV["DEPRECATION_DEBUG"] end end # config/application.rb module OneTribe class Application < Rails::Application # ... deprecators.debug = true if ENV["DEPRECATION_DEBUG"] end end Then I ran the specs with DEPRECATION_DEBUG=true ./bin/rspec and saw the following output: DEPRECATION_DEBUG=true ./bin/rspec DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. (called from load at ./bin/rspec:27) /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:15:in `block in all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `map' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:36:in `begin_transaction' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all.rb:24:in `block in begin_transaction' DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated and will be removed in Rails 8.0. Use #lease_connection instead. (called from load at ./bin/rspec:27) /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:15:in `block in all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `map' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `all_connections' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:36:in `begin_transaction' /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all.rb:24:in `block in begin_transaction' Now everything was clear. The warning was caused by the test-prof gem. I decided to ignore it for now and continue with the upgrade. test-prof Rails Deprecations Another deprecation warning I saw was: ➜ onetribe git:(rails-7-2) ✗ ./bin/rspec DEPRECATION WARNING: Defining enums with keyword arguments is deprecated and will be removed in Rails 8.0. Positional arguments should be used instead: enum :role, {:employee=>"employee", :manager=>"manager", :administrator=>"administrator"} (called from at /Users/igor/workspace/onetribe/app/models/member.rb:14) ➜ onetribe git:(rails-7-2) ✗ ./bin/rspec DEPRECATION WARNING: Defining enums with keyword arguments is deprecated and will be removed in Rails 8.0. Positional arguments should be used instead: enum :role, {:employee=>"employee", :manager=>"manager", :administrator=>"administrator"} (called from at /Users/igor/workspace/onetribe/app/models/member.rb:14) In mid-February 2024, there was a PR that deprecated defining enums with keyword arguments . Before it was possible to define enums like this: PR that deprecated defining enums with keyword arguments # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum allocation_type: { general: 0, extra: 1, auto: 2 }, _prefix: :allocation_type end # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum allocation_type: { general: 0, extra: 1, auto: 2 }, _prefix: :allocation_type end With this change you should define enums like this: # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum :allocation_type, { general: 0, extra: 1, auto: 2 }, prefix: :allocation_type end # app/models/time_off/slot.rb class TimeOff::Slot < ApplicationRecord # ... enum :allocation_type, { general: 0, extra: 1, auto: 2 }, prefix: :allocation_type end This new syntax eliminates the need to prefix options with an underscore. For some reason, this change wasn’t mentioned in the Rails 7.2 release notes, but it’s good to know about it. Application Configuration Update Rails has a special task rails app:update that can help you to update application configuration in an interactive mode. I use VS Code for development and wanted to use its merge tool, so as in the previous update, I specified THOR_MERGE constant before running the command THOR_MERGE="code --wait" ./bin/rails app:update and used merge tool ( m option) to track changes over files. rails app:update THOR_MERGE="code --wait" ./bin/rails app:update m During the update, I found only one notable configuration change. Annotation of views with filenames is now enabled by default in development. This setting is handled by config.action_view.annotate_rendered_view_with_filenames = true in config/environments/development.rb . config.action_view.annotate_rendered_view_with_filenames = true config/environments/development.rb Team Schedule Team Schedule With this setting enabled, you will see comments like this in the HTML source of the page. I am not sure if it’s useful, but it’s good to know about it. App Defaults After you merge all the changes, you can run the specs again to make sure everything is fine. Now it is time to make sure that your application is ready to run with Rails default settings, which are applied to every new Rails 7.2 application. This can be done in two steps. In config/initializers there should be a new file named new_framework_defaults_7_2.rb . It includes all Rails 7.2 default params commented, so you can enable them one by one and make sure that your specs are still green and your application is still working. config/initializers new_framework_defaults_7_2.rb After after, you can change config.load_defaults in config/application.rb file to have 7.2 value and delete new_framework_defaults_7_2.rb . This will enable all options at once. config.load_defaults config/application.rb 7.2 new_framework_defaults_7_2.rb Development Container One new feature of Rails 7.2 that deserves to be mentioned in this text is format support of Docker development containers. Yes, nobody prevented you from using dev container before Rails 7.2, but now you can generate container configuration for new apps with rails new myapp --devcontainer command. This will create a new Rails app with the .devcontainer folder that includes devcontainer.json , Dockerfile and docker-compose.yml files. rails new myapp --devcontainer .devcontainer devcontainer.json Dockerfile docker-compose.yml For applications that were upgrade you can use ./bin/rails devcontainer console command to generate the same files. ./bin/rails devcontainer Conclusions Since 7.2 is a minor release, there are not many changes and new features, however the Release Notes are rather long . I will not cover everything here, but I suggest you read them. Maybe I will write a separate post about some of the new features. Release Notes are rather long Stay tuned!