Upgrade Rails From 7.0 to 7.1

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 7.0 opens a new window to version 7.1 opens a new window .

1. Preparations
2. Ruby Version
3. Gems
4. Config Files
5. Rails Guides
6. Notable New Features
7. Application Code
8. Next Steps

1. Preparations

Before beginning with the upgrade process, we have some recommended preparations:

Your Rails app should have the latest patch version opens a new window before you move to the next major/minor version.
You should have at least 80% test coverage. We do have an article for strategies on upgrading with low test coverage opens a new window as well.
Have a staging environment that is as similar as possible to production, so that proper QA can be completed.
Check your Gemfile.lock for incompatibilities by using RailsBump opens a new window .
Create a dual boot mechanism, the fastest way to do this is installing the handy gem next_rails opens a new window . Find out more about how and why to dual boot opens a new window .
To learn more about dual booting with non-backwards compatible changes you can visit this article opens a new window .

For full details check out our article on How to Prepare Your App for a Rails Upgrade opens a new window .

2. Ruby Version

Rails 7.1 requires Ruby 2.7 opens a new window or later. Check out this table opens a new window to see all the required Ruby versions across all Rails versions.

3. Gems

Make sure you check the GitHub page of the gems you use for your application to find out its compatibility with Rails 7.1. In case you are the maintainer of the gem, you’ll need to make sure it supports Rails 7.1 and if it doesn’t, update it. A great tool to checkout gems compatibility is RailsBump opens a new window . We also encourage you to use the next-rails opens a new window gem and run bundle_report outdated to figure out which gems will need an update.

4. Config Files

Rails includes the rails app:update task opens a new window . You can use this task as a guideline as explained thoroughly in this post opens a new window .

As an alternative, check out RailsDiff opens a new window , which provides an overview of the changes in a basic Rails app between 7.0.x and 7.1.x (or any other source/target versions).

There are some config change in Rails 7.1 that could be helpful, or may cause you issues if not changed, so be sure to take time to checkout the diff.

5. Rails Guides

It is important to check through the official Rails Guides opens a new window and follow any of the steps necessary for your application.

6. Notable New Features

Generate Dockerfiles: Docker support is now available when generating new applications. This shouldn’t affect any of your current setup for the upgrade, but is a great feature that you will be able to take advantage of if desired.

7. Application Code

If you have ignored deprecation warnings on past version jumps, and haven’t stayed up to date with them you may find that you have issues with broken tests or broken parts of the application. If you have trouble figuring out why something is broken it may be because a deprecation is removed. The following is a list of the removals in Rails 7.1.

7.1 Railties

Remove deprecated bin/rails secrets:setup command.
Remove default X-Download-Options header since it is used only by Internet Explorer.
See full list of changes in the changelog opens a new window

7.2 Action Pack

Remove deprecated behavior on Request#content_type
Remove deprecated ability to assign a single value to config.action_dispatch.trusted_proxies.
Remove deprecated poltergeist and webkit (capybara-webkit) driver registration for system testing.
See full list of changes in the changelog opens a new window .

7.3 Action View

Remove deprecated constant ActionView::Path.
Remove deprecated support to passing instance variables as locals to partials.
See full list of changes in the changelog opens a new window

7.4 Active Record

Remove support for ActiveRecord.legacy_connection_handling.
Remove deprecated ActiveRecord::Base config accessors
Remove support for ``:include_replicas on configs_for. Use :include_hidden` instead.
Remove deprecated config.active_record.partial_writes.
Remove deprecated Tasks::DatabaseTasks.schema_file_type.
Remove --no-comments flag in structure dumps for PostgreSQL.
See full list of changes in the changelog opens a new window

7.5 Active Storage

Remove deprecated invalid default content types in Active Storage configurations.
Remove deprecated ActiveStorage::Current#host and ActiveStorage::Current#host= methods.
Remove deprecated behavior when assigning to a collection of attachments. Instead of appending to the collection, the collection is now replaced.
Remove deprecated purge and purge_later methods from the attachments association.
See full list of changes in the changelog opens a new window .

7.6 Active Support

Remove deprecated override of Enumerable#sum.
Remove deprecated ActiveSupport::PerThreadRegistry.
Remove deprecated option to passing a format to #to_s in Array, Range, Date, DateTime, Time, BigDecimal, Float and, Integer.
Remove deprecated override of ActiveSupport::TimeWithZone.name.
Remove deprecated active_support/core_ext/uri file.
Remove deprecated active_support/core_ext/range/include_time_with_zone file.
Remove implicit conversion of objects into String by ActiveSupport::SafeBuffer.
Remove deprecated support to generate incorrect RFC 4122 UUIDs when providing a namespace ID that is not one of the constants defined on Digest::UUID.
See full list of changes in the changelog opens a new window .

7.7 Active Job

Remove QueAdapter.
See full list of changes in the changelog opens a new window .

8. Next Steps

While we’ve provided a comprehensive guide to upgrading your Ruby on Rails application to version 7.1, it’s important to understand that the upgrade process may not always be straightforward. In some cases, Rails changes might affect certain aspects of your application in unexpected ways that aren’t explicitly highlighted in the release notes.

While we hope that your application is running smoothly after the upgrade, it’s crucial to be aware that it isn’t an absolute guarantee.

In such situations, it may require some debugging efforts to pinpoint the exact changes causing issues and determine the necessary refactors or adjustments.

This process can be time-consuming and may pose challenges, but it’s a part of the journey to keep your application up to date and secure.

If you find yourself in need of assistance and your team doesn’t have the time to tackle these challenges, you can always consider contacting us. Our experts are here to help you navigate the upgrade process and ensure your Rails application continues to thrive. opens a new window