In this blog post, I detail my journey upgrading a client’s Ruby from version 2.7 to 3.0. While some of the approaches I took may be tailored to their specific needs and might not directly apply to your situation, they offer insights into one possible path for upgrading Ruby, particularly in scenarios with limited test coverage.

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

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

When working on upgrades, we use the Dual-Boot technique so we can gradually update the app to work with the current version and the next one.

Eventually, the upgrade is done and the app is ready to drop the old version, but how do we handle that process? What are the steps between one upgrade and the next?

If you have ever upgraded Rails from 5.2 to 6.0, you might have run into issues with changes that had been made to the value of ActionDispatch::Response#content_type between the two versions.

If you have been lucky, you might not have even noticed there was a problem until Rails 6.0, after coming across this deprecation message:

Rails 6.1 will return Content-Type header without modification. If you want just the MIME type, please use `#media_type` instead. 

What happened with ActionDispatch::Response#content_type between Rails 5.2 to 6.1? In this article, we will go into some background to learn what this method does, look at the differences in ActionDispatch::Response#content_type’s return value between the several Rails versions, and how you can fix the problem if you come across it in your codebase.

When you upgrade a Rails application from Rails 6.1 to 7.0, you may suddenly see a lot of changes in the schema.rb file and wonder where those changes come from and how to deal with them.

In this post, we look at what those changes are, and how to deal with them when upgrading a Rails application.

At FastRuby.io, we don’t always run rails app:update in our process to upgrade Rails apps.

It might seem like a sacrilege - after all, that’s why the task was created, to make upgrading Rails as painless as possible, right? But we have found while upgrading dozens of applications that running rails app:update isn’t the best idea in all situations.

In this article, you will learn what rails app:update does, when it should not be used, and how to upgrade your Rails app without it.

Note: In Rails versions before 5.0, rails app:update was called rake rails:update.

Are you considering an upgrade for your Rails or Ruby application, but you’re concerned about low test coverage? Don’t worry! In this post, we’ll explore effective strategies to address the risks associated with low test coverage. By implementing these strategies, you’ll be able to upgrade your application with confidence. Let’s dive in!