Ruby on Rails 7.2

Rails 7.2 extended the 7.1-era framework with production and deployment defaults alongside application APIs. Newly generated applications gained a container-oriented deployment path with a Dockerfile and Kamal configuration, and Rails added development-container support. On compatible Ruby builds, new application configuration can enable YJIT in production. The cycle also added controller-level browser-version gating through allow_browser, allowing an application to reject unsupported browsers deliberately. In Active Record, ActiveRecord.after_all_transactions_commit provides a callback that runs after all currently open transactions have committed, which is useful when work must not run until nested or multi-database transactional work is complete. These additions did not require existing applications to adopt Kamal, containers, browser gating, or the new callback API, but upgrades can expose configuration and dependency differences that need review.

Rails 7.2 has reached end of life. It no longer receives upstream maintenance or security fixes, so a newly discovered framework vulnerability, compatibility defect, or regression affecting this line may require a local workaround, a private patch, or an upgrade under pressure. The risk is broader than the Rails gem: Ruby versions, database adapters, Rack, middleware, authentication libraries, asset tooling, and deployment images progressively move their tested combinations toward supported Rails lines. Remaining on 7.2 can therefore increase the cost of dependency updates and make production incidents harder to diagnose because reproductions may no longer match an actively maintained stack. Teams also retain operational risk if they depend on generated deployment defaults or container images that need updates outside the Rails release line.

First, record the exact Rails 7.2 patch level, Ruby version, Rack version, database adapters, background-job backend, JavaScript and asset tooling, and production container or deployment configuration. Move to the latest available 7.2 patch as a short-lived staging step if the application is behind, then upgrade to a currently supported Rails target using that target's release notes and upgrade guide. Run the full test suite, system tests, background-job tests, and production-like deployment checks after each upgrade step. Review all deprecation output before changing major versions, and use rails app:update only as a source of configuration diffs to review rather than overwriting local files. Test authentication and session behavior, parameter handling, database transaction callbacks, caching, Active Storage, jobs, mail, and any custom middleware. If adopting the 7.2 deployment, dev-container, YJIT, or browser-gating features, treat each as a separate operational change with its own rollout and rollback plan; they are not prerequisites for leaving 7.2.