Ruby 4.0

Ruby 4.0 succeeds the 3.x line and carries forward Ruby’s language, runtime, standard-library, RubyGems, and toolchain evolution. For most applications, source migration is expected to be incremental rather than a rewrite, but it is a major-version boundary: code or dependencies relying on deprecated APIs, implementation details, warning-free legacy behavior, or native-extension build assumptions may need changes. Treat the complete Ruby 4.0 release notes and the changelogs of every native dependency as part of the compatibility review.

Ruby 4.0 remains within its supported window, so staying on the latest maintained 4.0 patch release does not by itself create a support-gap risk. The trade-off is that a team postpones runtime improvements, newer language and standard-library capabilities, and compatibility work needed for the next Ruby line. The longer that work is deferred, the more likely the eventual upgrade is to combine Ruby changes with accumulated gem, compiler, operating-system, and CI-image changes. Native gems and dependencies that use Ruby implementation APIs are the highest-risk areas.

Standardize first on the latest Ruby 4.0 patch release and keep it current through normal maintenance. Run the full test suite with warnings enabled, audit direct and transitive gems for Ruby-version constraints and native extensions, and remove reliance on deprecated interfaces or implementation-specific behavior found by that work. Add CI coverage for the next Ruby line when it is available to your team, compare application and representative production-workload performance and memory use, and schedule the upgrade while the findings are small, isolated compatibility fixes rather than a bundled platform migration.