Ruby on Rails Support Lifecycle & Release History

Rails Minor Release Series: Bug Fix Windows and Security Fix Tracks

Each Rails minor release series receives exactly one year of bug fixes and two years of security fixes, both counted from the initial release date of that series -- after which the series reaches end-of-life with no further patches of any kind.

Rails targets a new minor release roughly every six months, meaning two active series typically overlap at any given time. One series is in its bug fix window, while an older one may still be receiving security-only patches. This cadence is intentional: it keeps the ecosystem moving without forcing teams into constant major upgrades.

Support is divided into three distinct tiers, each with its own scope:

In the rare case where no new minor release ships within one year, the Rails core team extends support for the previous release until the next one lands. This is an exception, not the norm, but it prevents teams from being stranded on an unsupported series through no fault of their own.

The EOL model is entirely date-driven and tied to the first release of each minor series -- not the latest patch. A series that released its first version two years ago is EOL regardless of whether a patch was published last month.

References: rubyonrails.org/maintenance -- Rails Guides: Maintenance Policy

Gem Rot, Middleware Drift, and Security Exposure in Unsupported Rails Series

Running an unsupported Rails series exposes your application to unpatched CVEs in the framework core -- including vulnerabilities in Active Record query generation, Action Pack routing, and Action View rendering, which are historically high-impact attack surfaces.

Beyond security, the more immediate day-to-day friction is gem incompatibility. The Rails ecosystem moves fast. Popular gems -- authentication libraries, API serializers, background job adapters -- start dropping support for older Rails series within months of EOL. You end up frozen: unable to update gems without upgrading Rails, but unable to upgrade Rails without updating gems first.

Ruby itself has its own EOL schedule, and Rails minimum Ruby requirements increase with each minor series. An EOL Rails version often pairs with an EOL Ruby version, compounding exposure at both the framework and runtime layers simultaneously.

Middleware and Rack compatibility is another friction point that gets overlooked. Web server adapters, Rack middleware, and deployment tooling (Puma, Thruster, Kamal) target current Rails conventions. Older series may encounter subtle behavioral differences as the surrounding infrastructure evolves around them.

Unsupported Series Phase-Out: What the Rails Core Team Stops Doing

Once a Rails series passes its two-year security fix window, the core team makes no further releases -- no patches, no backports to official gems, no changelogs. The series is frozen at its last published version permanently.

The core team may occasionally publish backported fixes to the Git branch without cutting a release, but this is informal and not guaranteed. You cannot rely on it as a support mechanism. If a critical CVE drops the day after EOL, there is no obligation for any patch to follow.

What remains available post-EOL: the source code on GitHub, the frozen gems on RubyGems.org, and community discussion. What disappears: any expectation of fixes, any coordination from core contributors, and any compatibility guarantees with future Ruby versions.

Migration Direction

Rails upgrades are designed to be incremental -- one minor version at a time. Skipping multiple series in one jump is possible but significantly increases the risk of hitting multiple deprecation removals simultaneously. The recommended path is to upgrade to each intermediate minor series, resolve deprecation warnings, then move to the next. The official upgrading guide documents breaking changes per series and is the authoritative reference for each step.

CLI Inspection: Identifying Your Active Rails Framework Version

Rails exposes its version through both the command line and the application runtime. The fastest check from a terminal:

rails --version

This outputs the Rails version of the rails binary in your current environment. If you use Bundler (which all Rails apps should), check the version locked in your app's Gemfile.lock instead -- the binary version and the app version can differ if you have multiple Rails versions installed globally.

To check the version locked to your specific application:

bundle exec rails --version

Inside a running Rails console, you can also query the constant directly:

$ bundle exec rails console
> Rails.version
# => "8.1.3"
> Rails::VERSION::MAJOR
# => 8
> Rails::VERSION::MINOR
# => 1

To see all Rails-related gems and their resolved versions in your project:

bundle list | grep railties

Cross-reference the minor version (e.g. 8.1, 7.2) against the release table above to determine whether your series is still receiving bug fixes, security fixes only, or is fully end-of-life.