Ruby confirms the end of 2.4 maintenance
The April announcement confirms that Ruby 2.4 support ended on March 31, after a final security release, and distinguishes the remaining branches by maintenance policy.
A final security patch can arrive at the same time that a runtime loses its future patch path. Ruby 2.4.10 is that kind of release. The April 5 support announcement confirms that all Ruby 2.4 support ended on March 31. Its publication date differs from the effective end of maintenance. The final patch gives existing users some time to move, without extending the branch's support period.
The team says it will no longer backport bug or security fixes to 2.4 and will not publish another patch release in that series. This is a policy change governing future maintenance. An existing application does not stop running when that policy takes effect, but its unchanged behavior no longer comes with an upstream route for correcting newly found defects.
I came to Ruby from Perl because I found its object-oriented model more consistent and approachable. That preference does not make an old interpreter a suitable permanent dependency. Keeping an application understandable includes knowing which parts still have maintainers responsible for correcting them.
The final release addresses a current defect
Ruby 2.4.10, published on March 31, includes the JSON security correction identified as CVE-2020-10663. Its announcement already describes the release as the likely last in the 2.4 series. The April notice removes uncertainty about the maintenance status.
The JSON advisory explains the defect. An earlier correction for unsafe object creation covered JSON.parse(user_input) but omitted other invocation forms, including JSON(user_input) and JSON.parse(user_input, nil). Certain inputs could still cause object creation that the application did not intend.
The advisory recommends JSON gem 2.3.0 or later and supplies a Bundler dependency declaration. Its scope is the JSON component, including copies bundled with Ruby. The interpreter's final release and the component's update are related corrective paths, but they do not establish a continuing maintenance commitment for the entire Ruby 2.4 branch.
That distinction matters when evaluating what the last patch accomplishes. Applying an available fix addresses the known defect covered by that release. It does not create a promise that another release will arrive for a future problem. The April announcement explicitly ends that promise.
Supported branches offer different kinds of maintenance
The notice places Ruby 2.6 and 2.7 in normal maintenance. Those branches can receive ordinary bug-fix backports and urgent corrections for critical security issues. Ruby 2.5 is in security maintenance, where ordinary bug fixes are no longer backported.
Moving from 2.4 to any supported branch therefore changes the maintenance position, but the destination branches are not interchangeable. A branch accepting only security fixes has a narrower policy than one accepting ordinary bug fixes. The decision concerns the kind of upstream correction available as well as whether a branch appears on a supported list.
For an application owner, this makes maintenance status a technical input. A defect can affect correctness without being classified as a critical security vulnerability. Under a security-only policy, its existence does not imply an upstream patch for that older branch. Normal maintenance gives a different set of expectations about such backports.
The announcement names the policies directly, which helps avoid interpreting every version greater than 2.4 as providing identical support. Version compatibility and maintenance coverage answer different questions. An application may build on a branch while the project has already narrowed the fixes it accepts there.
Component updates do not maintain the whole interpreter
The JSON advisory demonstrates that some bundled functionality can be updated through its gem. That is useful when the vulnerable code is distributed as an independently updatable component. It also means the version number of the interpreter alone does not describe every library loaded by an application.
The converse is equally relevant. An updated JSON gem does not provide fixes for unrelated code in an unsupported interpreter. A dependency update can resolve its own advisory without changing who maintains the runtime beneath it. The scope of the corrected component has to remain part of the explanation.
I prefer to describe an application's maintenance position at those actual boundaries. A fixed library and a maintained interpreter are separate properties. Combining them into one claim that the system is current would conceal which future updates remain available.
The announcement defines an end to backports
Ruby 2.4 spent its final year in security maintenance before this end of support. The final release is therefore the last stage of an already narrowed maintenance policy. The project has been reducing the branch's change scope, and the April announcement completes that process by ending further releases.
For an existing deployment, the substantive change is the absence of future upstream backports. Any continued use must account for that maintenance work elsewhere or move to a branch that still receives it. Ruby 2.4.10 supplies the final published correction in the series, while the support notice defines the limits of what follows that release.