Ruby 3.3

Ruby 3.3 added the experimental RJIT compiler and removed MJIT. YJIT received substantial work, including reduced memory overhead, code garbage collection, improved optimization coverage, and support for arm64 on supported macOS and Linux environments. The Prism parser shipped as a bundled parser for use by tools and applications, while the established CRuby parser remained relevant to runtime compatibility. The release also added a global regular-expression timeout through Regexp.timeout, providing an application-level control against excessively expensive regular-expression matches. Language and library changes included anonymous rest and keyword-rest argument forwarding, new and updated bundled gems, and other standard-library API additions.

Ruby 3.3 remains within its supported window, so staying on it does not by itself mean foregoing upstream maintenance. The practical trade-off is that teams do not gain runtime, parser, language, and standard-library improvements made in newer Ruby lines, including further work on JIT execution and parser integration. Dependencies may eventually raise their minimum supported Ruby version, particularly developer tools that rely on parser behavior or newer standard-library APIs. Deferring an upgrade can also make the eventual move larger: application code, native extensions, CI images, lockfiles, and production deployment environments then need validation across more intervening changes at once.

Keep Ruby 3.3 fully patched while planning an upgrade to the newest Ruby line your application and dependencies support. Build a CI matrix that runs the current production version alongside the target version, including every supported operating system and CPU architecture. Test code that uses reflection, dynamic evaluation, syntax-processing tools, regular expressions, native extensions, and JIT-related configuration, because these areas are more likely to expose runtime or tooling differences. Review Gemfile constraints and native gems early, update locked dependencies in controlled batches, and benchmark representative production workloads before deciding whether and how to enable YJIT or other runtime options on the target line.