Ruby on Rails 6.0

Rails 6.0 made the Zeitwerk code loader the default for new applications, replacing the older classic autoloader model and making file names, constants, and autoload paths more strictly conventional. It added built-in support for multiple databases, including separate connection roles for reading and writing, database-specific migrations, and horizontal sharding primitives. Action Mailbox added inbound-email routing, and Action Text added rich-text editing and storage through Trix. The test framework gained parallel test execution support. Rails 6.0 also introduced Host Authorization middleware to help defend against DNS rebinding attacks, expanded Active Storage capabilities, and continued the framework's move toward Webpacker-based JavaScript handling for new applications.

Rails 6.0 has reached end of life, so defects and security issues in this release line no longer receive upstream fixes. Staying on it leaves the application dependent on an older Rails security posture and increases the chance that required fixes must be carried locally or obtained through a commercial maintenance provider. Its dependency constraints can also make upgrades to current Ruby, database adapters, JavaScript tooling, and third-party gems harder, because maintainers commonly test and publish fixes against newer Rails lines. The longer an application remains on 6.0, the more likely it is that accumulated dependency changes and unaddressed deprecations will turn a controlled framework upgrade into a broader compatibility project.

Plan an upgrade through supported Rails release lines rather than jumping across several major versions without intermediate validation. First update the application to the latest available 6.0 patch level, run the full test suite, and remove all existing deprecation warnings. Audit autoloading with Zeitwerk checks, especially for files whose paths do not match their constants, custom autoload paths, concerns, and code that relies on load order. Review the Gemfile, Ruby version, database adapters, JavaScript packages, and deployment images against the target Rails version's requirements. Upgrade one Rails minor line at a time, using the official upgrade guide and release notes for each step, and test background jobs, mail handling, Active Storage, authentication, database migrations, and production configuration after every step. Deploy first to an environment that exercises real integrations, monitor errors and performance, and keep rollback procedures and database-migration compatibility in place before production rollout.