Ruby 3.2

Ruby 3.2 added Data, an immutable value-object facility defined with Data.define, and expanded pattern matching and argument-forwarding syntax. It introduced regular-expression timeouts, including a process-wide Regexp.timeout setting and per-regexp configuration, to help bound catastrophic backtracking. YJIT matured from an experimental feature into a supported just-in-time compiler option and received substantial performance and portability work. The release also added experimental WebAssembly/WASI support and updated bundled and default gems. These changes sit on top of Ruby 3.1, so applications moving from 3.1 need to account for parser and behavioral changes as well as dependency updates.

Ruby 3.2 has reached end of life, so upstream no longer provides maintenance releases or security fixes for this line. A newly discovered interpreter, standard-library, bundled-gem, OpenSSL, or dependency-installation issue may therefore require a local workaround, a backport maintained by the team, or an upgrade under pressure. Over time, gem authors, framework maintainers, and platform images increasingly test and ship against supported Ruby lines, making compatible dependency resolution and native-extension builds less predictable. Keeping 3.2 also prevents adoption of fixes and runtime improvements delivered in later Ruby releases, while the cost of a future upgrade generally grows as application and dependency baselines diverge further.

Select a currently supported Ruby target based on the application framework, deployment platform, and required gems; do not treat 3.2 as a long-term destination. Inventory every Ruby version declaration, CI image, container base image, buildpack, native extension, and lockfile that can constrain the upgrade. Run the full test suite and representative production workloads on the target Ruby, with warnings enabled where practical, then update incompatible gems and application code rather than suppressing failures. Test native extensions and TLS, database, background-job, and observability integrations in an environment matching production. Roll out through staging or a limited production cohort, monitor errors, memory use, startup behavior, and latency, and retain a tested rollback path. Until migration is complete, reduce exposure by keeping dependencies patched and applying compensating controls, while recognizing that they do not replace upstream fixes for the Ruby runtime.