I'm Hiroshi Shibata (hsbt), a Ruby committer and one of the branch maintainers responsible for Ruby's stable releases. I also maintain RubyGems and Bundler.
TL;DR
Since the March 2026 security releases of Ruby 3.3.11 and 3.2.11, no critical build issues or other problems have been reported. As announced in each release note, I'm now confirming: Ruby 3.2 has reached end-of-life, and Ruby 3.3 has moved to security-only maintenance.
If you're on either version, now is the time to plan your upgrade to Ruby 3.4 or 4.0. This post explains how Ruby's release cycle works, who maintains each branch, and what "security maintenance" actually means in practice.
What Happened in March
On March 26-27, 2026, we released Ruby 3.3.11 and Ruby 3.2.11 — both addressing CVE-2026-27820, a buffer overflow in Zlib::GzipReader. These weren't ordinary patch releases:
- Ruby 3.2.11 is the final release of the 3.2 series. No further updates of any kind will be provided. Ruby 3.2 had been supported for over three years since its initial release on December 25, 2022.
- Ruby 3.3.11 is the last normal maintenance release of the 3.3 series. From now on, Ruby 3.3 enters security-only maintenance for one year, until March 2027.
This kind of status transition happens every spring, roughly three to four months after the Christmas release of a new Ruby version. If you've been using Ruby for a while, the pattern might feel familiar. But the details of how it works aren't widely documented in English, so here's the full picture.
Ruby's Versioning: Not Quite Semver
Ruby follows a MAJOR.MINOR.TEENY scheme that looks like semantic versioning but isn't exactly:
- MAJOR increases when Matz decides the time is right. There's no predetermined criteria or schedule — it's entirely his call. The jump from 2.x to 3.0 happened when Ruby 3x3 (3x performance), Ractor (parallelism), and RBS (type signatures) came together. The jump to 4.0 brought ZJIT (a next-generation JIT compiler), Ruby Box (definition isolation), and Ractor improvements. Both bumps reflected Matz's judgment that the accumulated changes warranted a new major version.
- MINOR increases every Christmas. Each December 25, a new stable version ships. API-incompatible changes can and do appear in MINOR releases — for example, libraries moving from default gems to bundled gems, meaning you need to add them to your Gemfile explicitly. This surprises people coming from strict semver ecosystems.
- TEENY increases for bug fixes and security patches, released every two to three months. TEENY releases maintain API compatibility. The number can go above 9 — Ruby 3.2 reached 3.2.11.
The Christmas release cadence is one of Ruby's distinctive traits. It means every year, there's a predictable moment when a new version appears and the maintenance window shifts.
The Branch Lifecycle
Ruby doesn't have LTS (Long-Term Support) versions. Instead, every stable branch goes through the same lifecycle:
- Normal maintenance — receives bug fixes and security fixes. Lasts about two years.
- Security maintenance — receives only security fixes and critical build fixes. Lasts about one year.
- End of life — no further releases.
A stable branch typically lives for about three years total. At any given time, we maintain three or four branches simultaneously.
Here's the current state as of April 2026:
| Version | Status | Branch Maintainer | Notes |
|---|---|---|---|
| Ruby 4.0 | Normal maintenance | k0kubun | Released 2025-12-25 |
| Ruby 3.4 | Normal maintenance | nagachika | Released 2024-12-25 |
| Ruby 3.3 | Security maintenance | hsbt | Released 2023-12-25 |
| Ruby 3.2 | End of life | hsbt | Released 2022-12-25 |
And here's how the transition works each year:
December 25: New stable version released (e.g., 3.4.0)
→ 4 branches under maintenance for ~3 months
March-April: Oldest branch reaches EOL
→ Back to 3 branches
→ Second-oldest branch moves to security maintenance
December 25: Next stable version released
→ Cycle repeats
To see how this plays out concretely: in March 2025, Ruby 3.1 reached end-of-life with its final release 3.1.7, and Ruby 3.2 moved from normal maintenance to security-only maintenance. One year later, in March 2026, the same thing happened one version up — Ruby 3.2 reached end-of-life and Ruby 3.3 entered security maintenance. If the pattern holds, Ruby 3.3 will reach end-of-life in March 2027 when Ruby 3.4 moves to security maintenance.
Who Maintains What
Ruby's branch maintenance isn't a solo effort, but it's not a large team either. Currently, four people handle all stable releases:
- nurse (naruse) — maintains the development branch (master) and handles the Christmas release of each new stable version.
- k0kubun — maintains the latest stable version (currently Ruby 4.0). Releases every two to three months, sometimes faster when warranted.
- nagachika — maintains Ruby 3.4 (normal maintenance).
- hsbt (me) — maintains the security maintenance versions (currently Ruby 3.3) and handles branches until EOL (Ruby 3.2, now concluded). Also handles release infrastructure and automation.
This structure was formalized through a proposal in 2024 to streamline the teeny release workflow. Before that, branch maintainer assignments were less systematic.
I sometimes describe my coordination role as "release manager manager" — I don't just release my own branches, but also prepare templates for release announcements, ensure CDN publication works, purge negative caches, and automate as much of the process as possible so that other branch maintainers can ship releases with minimal friction.
What "Security Maintenance" Actually Means
The term "security maintenance" suggests we only fix CVEs during this phase. In practice, the scope is broader than that:
- Security fixes — any vulnerability with a CVE assignment gets patched.
- Critical build fixes — if a supported OS releases a new version and Ruby can't build on it, that gets fixed. Software breaks if you leave it alone; keeping Ruby buildable on current platforms is part of the job.
- Test fixes — if CI platforms we test against cause test failures, we fix the test code to keep the suite green. This lowers the barrier for future emergency releases.
The goal is simple: if you're running Ruby 3.3 in production for the next year, it should keep building and running on the platforms you actually use. We won't add features or fix minor bugs, but we won't let it rot either.
If you discover a security vulnerability in Ruby, please report it through HackerOne. For bundled gems, you can also use GitHub's private vulnerability reporting on the gem's repository. We've been gradually migrating to GitHub for bundled gems since it allows the maintainers of each gem to handle the process directly.
How a Release Gets Made
For a normal teeny release, the process looks roughly like this:
- Bug fixes land on master first, then get backported to stable branches. For the latest stable version, contributors actively triage and create patches, which the branch maintainer backports. For older branches, I cherry-pick fixes manually.
- The branch maintainer runs CI across all supported platforms and fixes anything that breaks.
- When ready, the maintainer tags the release. From that point, automation takes over — packages are built, tested, and published.
- The release announcement is posted on ruby-lang.org.
If you've found a bug that's been fixed on master but hasn't made it into a stable release yet, you can request a backport. The process is documented in the How To Request Backport wiki page. In short: file a ticket on bugs.ruby-lang.org with the commit hash in the subject (e.g., "Backport abcde123"), and the branch maintainer will pick it up. Generally, only bug fixes are eligible for backport — feature additions stay on master. Even better, you can open a pull request directly against the target branch (e.g., ruby_3_4) on GitHub. This saves the branch maintainer time and gets your fix into the next release faster.
What This Means for You
If you're on Ruby 3.2: upgrade now. There will be no more releases, not even for security issues.
If you're on Ruby 3.3: you have until March 2027, but only security fixes will be backported. Start planning your upgrade.
If you're on Ruby 3.4 or 4.0: you're in good shape. Normal maintenance continues.
One exception: if you're using Ruby packages provided by a Linux distribution such as RHEL, Ubuntu, or Debian, the upstream EOL dates above don't directly apply to you. Those distributions maintain their own packages and backport security fixes according to their own support lifecycle. Check your distribution's documentation for the actual support timeline of the Ruby version you're running.
Check the official branch status page for the latest maintenance status: ruby-lang.org/en/downloads/branches/
For details on what changed in each version, the NEWS file in Ruby's source tree is the authoritative reference. If you want to catch deprecation warnings in your application, try running with ruby -w to enable all warnings including deprecations.
Notes
- Written in April 2026. Branch status and maintainer assignments may change over time.
- I'm a Ruby committer and branch maintainer. This reflects my perspective on how the process works in practice.
Top comments (0)