Forem: SHIBATA Hiroshi

Is Your Ruby Version Still Supported? A Maintainer's Guide to Ruby's Release Cycle

SHIBATA Hiroshi — Mon, 06 Apr 2026 07:25:38 +0000

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.

Should RubyGems/Bundler Have a Cooldown Feature?

SHIBATA Hiroshi — Thu, 19 Mar 2026 01:45:21 +0000

I'm Hiroshi Shibata (hsbt), a Ruby committer and the maintainer of RubyGems and Bundler.

TL;DR

Every major package manager is adding "cooldown" — a waiting period before you can install newly released packages. RubyGems/Bundler doesn't have one yet. I've been discussing whether we should add it. Short answer: yes, as an opt-in option, but cooldown alone isn't enough.

What Is a Cooldown?

A cooldown prevents upgrading to a new package version until a certain time has passed since its release. The idea is simple: if a malicious package is published, the waiting period gives security researchers time to catch it before it reaches your Gemfile.lock.

William Woodruff's analysis found that 8 out of 10 supply chain attacks he examined had an exploitation window of less than one week. A 7-day cooldown could have prevented most of them.

As Andrew Nesbitt summarizes in "Package Managers Need to Cool Down", from late 2025 into 2026, cooldown adoption has accelerated rapidly.

The Landscape

Cooldown started in dependency update tools, then spread to package managers themselves. One complication: every tool picked a different config name — minimumReleaseAge, min-release-age, npmMinimalAgeGate, exclude-newer, uploaded-prior-to, and so on. At least 10 different names exist. Polyglot developers, beware.

Dependency Update Tools

Dependabot added a cooldown block in July 2025. You can set different waiting periods per semver level, and security updates bypass the cooldown:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
      semver-major-days: 7

Renovate has minimumReleaseAge (formerly stabilityDays), with per-package and per-update-type granularity:

{
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "minimumReleaseAge": "7 days"
    }
  ]
}

Package Managers

pnpm was first, shipping minimumReleaseAge in v10.16 (September 2025):

# pnpm-workspace.yaml
minimumReleaseAge: 1440  # 24 hours
minimumReleaseAgeExclude:
  - '@myorg/*'

npm followed with min-release-age in CLI 11.x (February 2026). Bun added minimumReleaseAge in October 2025, Deno added --minimum-dependency-age. All major JavaScript runtimes now support cooldowns.

On the Python side, uv extended its --exclude-newer flag (originally for reproducible builds) to accept relative durations like "7 days". pip introduced --uploaded-prior-to in 26.0 (January 2026), though pip only takes absolute timestamps.

Where Does Ruby Stand?

RubyGems and Bundler have no cooldown feature. A community member opened a Discussion on ruby/rubygems requesting one, and I discussed it with Ruby community members and the RubyGems team.

What follows is my take on the discussion. I'm the RubyGems/Bundler maintainer, so keep that bias in mind.

The "guinea pig" problem

My first concern. Cooldowns implicitly assume that someone else will install the new version first and find problems. But if everyone enables cooldowns, nobody tries new releases during the waiting period — and the mechanism becomes useless. Better than nothing, probably. But it's a structural limitation of how OSS works.

Delayed security fixes

A strict cooldown also delays urgent security patches. Distinguishing a malicious release from a legitimate security fix automatically is extremely difficult. Cooldowns could actually increase risk in some cases.

The illusion of safety

Software that hasn't been updated in 10 years may contain undiscovered vulnerabilities. Consider a gem that's been on RubyGems for years without updates — age tells you nothing about whether it's been audited. Time passing doesn't guarantee security. Cooldowns provide a sense of security, but a sense of security isn't the same as actual security.

Buying time for security researchers

On the other hand — and this is the strongest argument for cooldowns — they buy time for people who are actually scanning packages.

A concrete example: Maciej Mensfeld, a member of the RubyGems security team and developer of Diffend (a supply chain security platform for Ruby). He has detected and reported over 20,000 malicious packages across ecosystems.

In the RubyGems ecosystem specifically, he found over 700 typosquatting gems in 2020 (e.g., rail targeting rails), and in 2022, more than 400 malicious packages were removed. His RubyKaigi 2023 talk "RubyGems on the watch" covers these efforts.

Today, the security team including Maciej reviews gems after release on rubygems.org. Gems found to contain malicious code are removed. A cooldown isn't just about waiting — it becomes effective when combined with this kind of scanning infrastructure.

What We're Considering

My current thinking: offer cooldown as an opt-in option in the short term, pursue more technically effective measures longer term.

Bundler Cooldown Option

Enterprise environments want this. Dependabot and Renovate already have equivalent features, so it makes sense to support it at the Bundler level too.

What the spec might look like:

bundle update --cooldown 3 (CLI option)
bundle config set cooldown 3 (global config)
Block syntax in the Gemfile for per-gem cooldowns
gem install support for CI/CD environments like GitHub Actions

Opt-in, disabled by default. Users choose based on their own needs.

Scanning and Metadata on RubyGems.org

To make cooldowns actually useful, "has this gem been scanned?" matters as much as "has enough time passed?" On the rubygems.org side, we're considering:

Automated scanning of new releases, with scan status published as index metadata
Delays for high-risk releases (recent ownership changes, Trusted Publishing disabled)
Letting RubyGems/Bundler reference this metadata to adjust behavior

There's also been a suggestion for a "scanned" badge on rubygems.org — worth exploring.

Beyond Cooldown

Separately, there's discussion about sandboxing code execution during gem install: ruby/rubygems#9138.

RubyGems and Bundler recently landed a change that separates the download and install phases: ruby/rubygems#9381. This was for performance, but the separation opens the door to running SAST or other verification after download and before install — potentially more effective than cooldown alone.

Conclusion

Cooldown is not a silver bullet. But combined with server-side scanning and metadata on rubygems.org, it can be a meaningful layer of defense. We plan to offer it as an opt-in option in RubyGems/Bundler.

If you have thoughts, join the GitHub Discussion.

Notes

Written in March 2026. The ecosystem is evolving quickly — specifics may change.
I'm a Ruby committer and the maintainer of RubyGems/Bundler. My perspective is shaped by that role.