How to Upgrade to Rails 6

Oh, you just never stop learning with Rails. 15+ years old, and still there’s always something new. The all new version Rails 6.0.0 is here. Many developers will have the chance to upgrade their existing apps and use some brand new features.

As of a few weeks since release, here is a guide on how to upgrade your existing web and mobile applications development and get started with it.

• ▪ 1.Things to consider before upgrading Before making any Rails upgrade, you need to ensure that the current code is stable and is well tested. Any major upgrade comes with the likelihood of breaking changes, and Rails 6 is no exception!
• ▪ 2.Update your Ruby version to minimum 2.5 version The first change that would come with New Rails 6 is the minimum Ruby version it needs. While Rails 5.0 requires at least Ruby 2.2.2, Rails 6 will make you upgrade to Ruby 2.5.0 or higher. In case, you are using rbenv and Homebrew, you can easily do by running a few commands .brew update && brew upgrade ruby-build rbenv install 2.6.0

  • ▪ 2.1 Upgrading from Rails 3.0 to Rails 3.1 If your app is presently under any older versions than 3.0.x, then you need to upgrade to Rails 3.0 before upgrading to Rails 3.1. Following changes are required for upgrading your application to Rails 3.1.12.

    • ▪ Gemfile: Make some changes to the Gemfile.
    • ▪ config/application.rb: Make some additions to the asset pipeline. If your app is using an “/assets” route for a resource, you can change the prefix used for assets in order to avoid conflict.
    • ▪ config/environments/development.rb: Remove the RJS setting config.action_view.debug_rjs = true. Plus, you can add few settings for enabling the asset pipeline.
    • ▪ config/environments/test.rb: Test the performance by including few additions to your test environment.
    • ▪ config/initializers/wrap_parameters.rb: Add file with command contents if you want to wrap parameters into a nested hash. For more information, you can refer to the document.
    • ▪ config/initializers/session_store.rb: You need to change the session key to something new, or you can remove all sessions.
    • ▪ Remove :cache and :concat options in asset helpers references in views: As the Asset Pipeline the :cache and :concat options are not much used now, you can delete these options from your views.

  • ▪ 2.2 Upgrading from Rails 3.1 to Rails 3.2 If your app is currently on any other Rails versions older than 3.1.x, you need to upgrade to Rails 3.1 before trying to upgrade to Rails 3.2. Following changes are required for upgrading your application to Rails 3.2.x,

    • ▪ Gemfile: Make few changes to the Gemfile.
    • ▪ config/environments/development.rb: There are few new configuration settings you need to add to the development environment.
    • ▪ config/environments/test.rb: Add the mass_assignment_sanitizer configuration setting to the
    • ▪ config/environments/test.rb: Vendor/plugins: Rails 3.2 doesn’t support vendor/plugins. Though it isn’t strictly necessary for upgrading, you can start replacing the plugins by extracting them to gems and add them to the Gemfile. But, if you want not to make them gems, you can move them into_ lib/my_plugin/*_ and add appropriate initializer in config/initializers/my_plugin.rb.
    • ▪ Active Record: If you want to avoid deleting object or associated objects, you can set dependent => :destroy and return false after checking for existence of association from any of the associated object’s destroy callbacks.

  • ▪ 2.3 Upgrading from Rails 3.2 to Rails 4.0 If your app is currently on any other Rails versions older than 3.2.x, you need to upgrade to Rails 3.2 before trying to upgrade to Rails 4.0. Following changes are required for upgrading your application to Rails 4.0,

    • ▪ HTTP PATCH: Rails 4 uses PATCH as primary HTTP verb for getting updates when a RESTful resource is found in config/routes.rb. The update action is still used, and PUT requests are used to rout to the update action. In case, you are using only the standard RESTful routes, no changes need to be done. If you are using form_for to update a resource in conjunction, make a change using the PUT HTTP method.
    • ▪ Gemfile: Rails 4.0 has removed asset group from the Gemfile. You need to remove the line from your Gemfile while upgrading. You can upgrade your app file (in config/application.rb).
    • ▪ Vendor/plugins: As Rails 4.0 do not support loading plugins from vendor/plugins, you need to replace the plugins by extracting them to gems and putting them to the Gemfile. If you don’t want to make them gems, you can move them into lib/my_plugin/* and put an appropriate initializer in config/initializers/my_plugin.rb.
    • ▪ Active Record: Rails 4.0 has removed identity map from the Active Record because of variations with associations. If you have manually put it in your app, you need to remove the config which has no effect.For more information, you can refer to the document.
    • ▪ Active Resource: Rails 4.0 can extract Active Resources to its own gem. If you need the feature, you can add the Active Resource gem in your Gemfile.
    • ▪ Active Model: Rails 4.0 has changed the way errors are attached with the ActiveModel::Validations::ConfirmationValidator. If the confirmation validations fail, the errors can be attached to: #{attribute}_confirmation instead of attribute.Rails 4.0 has changed ActiveModel::Serializers::JSON.include_root_in_json default value to false. Now, Active Model Serializers and Active Record objects have similar default behaviour, which means that you can comment and remove the option in the config/ initializers/wrap_parameters.rb file.
    • ▪ Action Pack: Rails 4.0 announces ActiveSupport::KeyGenerator and practices this as a base from which one can generate and authenticate signed cookies (among other things). Present signed cookies produced with Rails 3.x will be clearly upgraded if you leave your existing secret_token in place and put the new secret_key_base. For more information, you can refer to the document.
    • ▪ Active Support: Rails 4.0 takes out the j alias for ERB::Util#json_escape since j is previously used for ActionView::Helpers::JavaScriptHelper#escape_javascript.
    • ▪ Active Record Observer and Action Controller Sweeper: ActiveRecord::Observer and ActionController::Caching::Sweeper can be pulled out to the rails-observers gem. If you want more features, you need to add rails-observers gem
    • ▪ sprockets-rails: As assets:precompile:primary and assets:precompile:all are removed, you can use assets:precompile. Change config.assets.compress option to config.assets.js_compressor.
    • ▪ sass-rails: asset-url with two arguments is deplored. For example: asset-url(“rails.png”, image) has become asset-url(“rails.png”).

  • ▪ 2.4 Upgrading from Rails 4.0 to Rails 4.1

    • ▪ CSRF protection from remote <script> tags: Cross-site request forgery (CSRF) protection can cover GET requests with JavaScript responses. This does not allow third party site to remotely reference your JS with a <script> tag to derive sensitive data.
    • ▪ Spring: For using Spring as your app preloader, you need to follow the following steps:
      • ▪ Add gem ‘spring’, group: :development to your Gemfile.
      • ▪ Connect spring using bundle install.
      • ▪ Springify your binstubs with bundle exec spring binstub –all

  • ▪ 2.5 Upgrading from Rails 4.1 to Rails 4.2

    • ▪Web Console: At first, you can add gem ‘web-console’, ‘~> 2.0’ to the :development group in the Gemfile. Run bundle and install. After installation, you can drop a reference to the console helper (i.e., <%= console %>) into any view you want to enable for. A console can be provided on any error page you view in the development environment.
    • ▪ Responders: The respond_with and the class-level respond_to methods have been pulled out to the responders’ gem. For using them, just add gem ‘responders’, ‘~> 2.0’ to the Gemfile. Calls to respond_with and respond_to (at class level) will not work without having included the responders gem in the dependencies.
    • ▪ Error handling in transaction callbacks: Now, Currently, Active Record overwhelms errors elevated within after_rollback or after_commit callbacks and prints them to the logs. In the next version, these errors will not be suppressed. As an alternative, the errors will proliferate normally just like in other Active Record callbacks.After you define an after_rollback or after_commit callback, you will get a deprecation warning about this imminent change. After you are ready, you can go into the new behaviour and take out the deprecation warning by adding configuration to the config/application.rb.

  • ▪ 2.6 Upgrading from Rails 4.2 to Rails 5.0

    • ▪Ruby 2.2.2+ required: You need to install minimum Ruby 2.2.2 version for upgrading to Ruby 5.0 onwards.
    • ▪ Active Record Models Now Inherit from ApplicationRecord by Default: In the Rails 4.2, an Active model inherits from the ActiveRecord::Base. In the Rails 5.0 version, all the models inherit from ApplicationRecord. For more information, you can refer to the document.

  • ▪ 2.7 Upgrading from Rails 5.0 to Rails 5.1

    • ▪ Top-level HashWithIndifferentAccess is soft-deprecated: If the app utilises top level HashWithIndifferentAccess class, you can move your code to use ActiveSupport::HashWithIndifferentAccess. It is a bit soft deprecated and it means that the code won’t break at the moment and no disapproval warning will be shown, but this constant will be removed in the future.
    • ▪ application.secrets now loaded with all keys as symbols: If the app stores similar configuration in config/secrets.yml, then all the keys are loaded as symbols, therefore, you need to change the access using the strings. For more information, you can refer to the document.

  • ▪ 2.8 Upgrading from Rails 5.1 to Rails 5.2

    • ▪ Bootsnap:Rails 5.2 brings bootsnap gem in the newly generated app Gemfile. The app:update command sets it up in the boot.rb. For using it, you need to add it to the Gemfile or change the boot.rb not to use the bootsnap.
    • ▪ Expiry in signed or encrypted cookie is now embedded in the cookies values: For more security, Rails is now embedding the expiry data both in encrypted and signed cookies value. This new embedded data makes those cookies incompatible with Tails version older than 5.2. For more information, you can refer to the document.

  • ▪ 2.9 Upgrading from Rails 5.2 to Rails 6.0

    • ▪ Using Webpacker: Webpacker is default JS compiler for Rails 6. But, without upgradation, the app is not activated by default. For using Webpacker, you need to include it in your Gemfile and install it.
    • ▪ Force SSL: force_ssl method for controllers has been deprecated and will not be part of Rails 6.1. Users can enable config.force_ssl for enforcing HTTPS connections in the app. For exempting few endpoints from redirection, use config.ssl_options for configuring that behavior.

All npm packages is now moved to the @rails scope: If you were previously loading any of the actioncable, activestorage, or rails-ujs packages using npm/yarn, you need to update the names of these dependencies before you start upgrading them to 6.0.0. For more information, you can refer to the document.

• ▪ 3.Check 3rd Party Gems for application compatibility You need to check all the third-party gems that your application is using and ensure that those gems support the current rails version that you are upgrading to. Orelse it might not function as intended or it may break the app. Check the gems/plugins the application has. If some of the gems doesn’t support the rails version that you are trying to upgrade to, then you need to see how you can fix it or replace the gem with another library that supports the targeted version.

• ▪ 4.Update Gemfile As the version you install is in beta form, you will need to update the Gemfile with github: ‘rails/rails’, gem ‘rails’, & run bundle update rails.

• ▪ 5.Update Task to configure your app Run your rails app: update to configure your app. This leads you to a step by step process by adding few configuration settings into the application. It is an interactive process but can sometimes lead to some unexpected problems if precaution is not followed.

• ▪ 6.Uncomment defaults Uncomment defaults in new_framework_defaults_6_0.rb. The comment at the top of file is a bit confusing as it advises users to “flip default” instead of just uncommenting the flags. This will make them go back to Rails 5.0, whereas after updating from Rails 4.2, the flags were uncommented and were set to false by default. And, they were supposed to be switched to true. However, this isn’t the case in Rails 6.0 here. The flag already has correct values. One can fix the comment in the final release.

• ▪ 7.Add any missing gems and bundle Every major Rails version comes up with a slightly different set of gems. However, the rails app:update command isn’t that helpful. Without manual change and dependencies, the application might break down. So, one needs to add any missing gems in the app.

• ▪ 8.Run Migrations Run rails db:migrate command to run migrations. It is an easier method of altering your database schema over time.

• ▪ 9.Run the tests and fix the failing ones Once you make the update, deprecation warnings can take the majority of the output you would get from the tests. Try to fix them quickly. Plus, if you don’t want much stress; you can hide them using command ActiveSupport::Deprecation.silenced = true.But again, what’s the advantage in hiding when you know this issue would be cropping up some time later. So, why not do it right now. Fix all the failing ones, as the upgrade would get easier as the time passes.

• ▪ 10.Perform manual tests Watch out for any leftovers. Open the page on the server and check manually if you have overlooked anything. This will help you get a green signal for pushing the app into staging and production stage.

• ▪ 11.Finally, staging and production Before you go live, use the existing staging to test the application in an environment which is closer to production. If possible, you can bring some other people to test it with you. The Rails 6.0.0.rc1 version is all here. RoR’s convention over configuration strikes again and provides an easier method of offering rich text editing option to users. Now is a good time if you have been seriously considering an upgrade. What’s more, the procedure becomes much easier if you have all the dependencies up to date and have good test coverage.

If you're not on Rails 6.0 yet, We can help. Talk to our Ruby on Rails experts for all your development needs right now.