Ruby 2.5

Ruby 2.5 added several core-library conveniences, including Kernel#yield_self, Hash#slice, Hash#transform_keys, Hash#transform_keys!, String#delete_prefix, String#delete_suffix, File.write, and File.binwrite. It also introduced an experimental just-in-time compiler, MJIT, alongside incremental performance and memory-management work. Bundler was distributed as a default gem, making it part of the standard Ruby installation while retaining its own versioning and update path. These changes made common transformations and file operations less verbose, but MJIT was experimental and should not be treated as a stable performance feature for an upgrade plan.

Ruby 2.5 has reached end of life, so upstream no longer provides security fixes, bug fixes, or compatibility maintenance for this line. A vulnerability in the interpreter or its bundled and default components generally requires migration or a locally maintained patch rather than an upstream 2.5 update. Dependency risk increases over time because gem authors, build tools, operating-system packages, and native extensions can raise their minimum supported Ruby version. Teams can become unable to update a vulnerable dependency without also changing Ruby, while older locked dependencies accumulate their own known security and compatibility issues. Running an obsolete Ruby also makes it harder to use supported TLS, OpenSSL, compiler, and platform combinations, particularly for applications with native gems.

Plan a move to a currently supported Ruby line rather than treating Ruby 2.5 as a long-term platform. First, record the exact Ruby, Bundler, RubyGems, operating-system, compiler, OpenSSL, and native-gem versions used in each environment, then make the test suite and deployment build reproducible from that inventory. Run the application and its test suite against the target Ruby in CI, updating dependencies in controlled groups and checking each native extension for target-Ruby and target-platform support. Review application code and dependencies for deprecated behavior, changed standard-library packaging, keyword-argument compatibility, encoding assumptions, and subprocess or TLS behavior. Update lockfiles only with automated tests, security scanning, and production-like smoke tests in place. Deploy through a canary or phased rollout, monitor errors, memory use, latency, and background-job behavior, and retain a tested rollback path while the new runtime is validated.