DEV Community: SHIBATA Hiroshi

What's New in RubyGems/Bundler 4.1, Part 1: override and prune

SHIBATA Hiroshi — Fri, 09 Oct 2026 05:22:10 +0000

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

TL;DR

RubyGems and Bundler 4.1.0.beta2 shipped on October 8, 2026. This is Part 1 of a three-part series on what's new in 4.1, and it covers two features. override in the Gemfile rewrites version constraints declared by your dependencies, transitive ones included, and can even drop or replace a dependency. The prune setting makes Bundler delete download caches and .git directories after install, replacing the rm -rf line in your Dockerfile. Both hand back to you a decision RubyGems and Bundler used to make on their own, and both are opt-in. Nothing changes until you ask for it.

`override` in the Gemfile

When an upper bound gets in your way

A gem you depend on declares something like < 2.0. You know the newer version works, but the resolver still refuses. The same thing happens with Ruby itself. If a gemspec's required_ruby_version has an upper bound like < 4.1, the gem stops installing the moment you upgrade to Ruby 4.1, even if it actually works.

Preview releases hide this problem. RubyGems sees a preview or rc Ruby as a prerelease version like 4.1.0.preview1, which satisfies < 4.1. You can test everything on the preview and still hit the wall on release day.

Until now, you could fork the gem and maintain it yourself, or wait for upstream to relax the constraint. Both cost far too much for a single line.

The request is old. ruby/rubygems#4178 was opened in December 2020 and stayed open until May 2026, a week after override was merged. I also tried adding a setting like ignore_ruby_upper_bounds in ruby/rubygems#9454, but byroot and Edouard-chin pointed out in review that this belonged in the Gemfile DSL. After the discussion in ruby/rubygems#9494, we settled on the current override.

Syntax

override <target>, <field>: <operation>

The target is a gem name string or :all. The field is version:, required_ruby_version:, or required_rubygems_version:, for the dependency's version requirement, the Ruby version requirement, and the RubyGems version requirement. There are three operations.

A requirement string replaces the existing constraint entirely. The original constraint is discarded, whether it comes from a direct or a transitive dependency.
:ignore_upper removes the upper-bound operators < and <=. ~> collapses into a >= that keeps only the lower bound.
nil drops every constraint and leaves >= 0.

Here is what each operation does.

Original         Operation        Result
>= 1.0, < 2.0    ">= 8.0"         >= 8.0
~> 1.5           :ignore_upper    >= 1.5
>= 1.0, < 2.0    :ignore_upper    >= 1.0
!= 1.2, < 2.0    :ignore_upper    != 1.2
= 0.9.1          nil              >= 0

Keeping != 1.2 under :ignore_upper is intentional. The first implementation used an allow-list that kept only lower bounds, but that brought back versions the user had explicitly excluded, such as one with a known vulnerability. Review caught it, and I switched to a reject-list that drops only the upper-bound operators.

It reaches transitive dependencies

What makes override worth having is that it works on dependencies you never wrote yourself. Say qux depends on bar (< 2.0), and bar 2.0 is out but you can't use it.

source "https://rubygems.org"
gem "qux"

Resolving this Gemfile stops bar at 1.0.

    bar (1.0)
    qux (1.0)
      bar (< 2.0)

Add one line of override.

source "https://rubygems.org"
override "bar", version: :ignore_upper
gem "qux"

Run bundle update bar, and bar moves to 2.0.

    bar (2.0)
    qux (1.0)
      bar (< 2.0)

The gemspec of qux hasn't changed, so the lockfile still records bar (< 2.0) under it. Yet the resolved version is 2.0.

The lockfile doesn't record `override`

That lockfile looks contradictory because override itself is never written to it. Gemfile.lock holds only the result of resolution, not which constraints were rewritten or how. This was a design decision from byroot's review. The Gemfile already holds the override, so recording it again in the lockfile adds no information.

Since nothing is recorded, adding an override to an existing lockfile keeps the locked version as long as it satisfies the rewritten constraint. That's why the example above needed bundle update bar. Bundler can't tell from the lockfile whether the override was just added, and re-resolving whenever one is present would update gems on every bundle install. If the locked version no longer satisfies the constraint, as with version: ">= 2.0", Bundler re-resolves right away.

The flip side is that the lockfile alone can't tell you why a particular version was chosen. When you use override, leave the reason as a comment in the Gemfile. Whoever touches it next will thank you.

When resolution fails, Bundler lists the active overrides at the end of the error.

Bundler applied the following overrides while resolving:
  override "bar", version: "= 3.0" (declared at Gemfile:2)

Ruby and RubyGems version requirements

The other two fields apply to the Ruby and RubyGems requirements a gem declares in its metadata. They're for the moment right after a Ruby upgrade, when a gem that hasn't caught up blocks you with its required_ruby_version.

override :all, required_ruby_version: :ignore_upper

Only these two fields accept :all, which targets every gem at once. :all with version: is rejected, because a dependency's version requirement only makes sense per gem. When a gem has both a per-gem entry and an :all entry, the per-gem one wins.

As with version:, adding this to an existing lockfile keeps the locked versions.

1. Before adding                 selectable (1.0)
2. Add :all, run bundle lock     selectable (1.0)
3. Then run bundle update        selectable (2.0)
4. Resolve without a lockfile    selectable (2.0)

:all covers every gem in one line, so without this behavior it would move unrelated gems too.

Dropping or replacing a dependency with `from:` and `to:`

4.1.0.beta2 adds from: and to:, which rewrite the dependency itself instead of its version constraint. This started with byroot asking in ruby/rubygems#9517 whether there was a way to avoid installing a problematic dependency at all. For example, jekyll only loads em-websocket for jekyll serve --livereload, yet always installs it.

Let's go back to qux and bar. To drop the dependency of qux on bar, set from: to the depending gem and to: to nil.

source "https://rubygems.org"
override "bar", from: "qux", to: nil
gem "qux"

After resolving, bar disappears from the lockfile's gem list.

    qux (1.0)
      bar (< 2.0)

bar (< 2.0) stays under qux as published, because the lockfile records a gem's declaration without rewriting it, just as with version overrides. Remove the override line and resolve again, and bar comes back at 1.0.

To replace it with another gem, put that gem's name in to:. This is for cases where a lighter, API-compatible gem exists.

source "https://rubygems.org"
override "bar", from: "qux", to: "bar-lite"
gem "qux"

    bar-lite (1.0)
    qux (1.0)
      bar (< 2.0)

The < 2.0 that qux put on bar is dropped. If the replacement needs a version constraint, add version: alongside, as in to: "bar-lite", version: ">= 2.0".

Bundler doesn't look at what a gem requires at runtime. If qux loads bar unconditionally, dropping it gives you a LoadError. A replacement only works when it provides the files qux loads. The replacement also doesn't take the original name, so bar won't appear in Gem.loaded_specs.

An override that would leave the original gem in the bundle anyway is an error. You can't drop a gem listed directly in the Gemfile. If you try to replace bar while another gem still depends on it, Bundler asks you to write an override for each dependent.

override "bar", from: "qux", to: "bar-lite" (declared at Gemfile:2) would leave
both bar and bar-lite in the bundle because bar is still required by:
  corge
Replace it for each of them, for example:
  override "bar", from: "corge", to: "bar-lite"

`prune` in Bundler

Turning the Dockerfile `rm -rf` into a setting

The Dockerfile that Rails generates contains this line.

RUN bundle install && \
    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git

After bundle install, it deletes the download cache and the .git directories of git gems. Neither needs to stay in the image, and keeping them only wastes space. prune moves this hand-written cleanup into Bundler. It was requested in ruby/rubygems#7018 back in 2020 and landed in ruby/rubygems#9815.

prune only removes artifacts that Bundler creates for its own purposes and can rebuild from the lockfile. It never touches gem contents. There are two categories. cache is the cache directory under the bundle path, which holds both .gem files and git mirrors. git is the .git directory of checked-out git gems. These match the two parts of the rm -rf above that Bundler can handle.

Usage

bundle config set --local prune cache:git

The environment variable is BUNDLE_PRUNE. Categories can be separated by spaces or :.

BUNDLE_PRUNE=cache:git bundle install

Any value that isn't a category name is read as a boolean, and a true value enables every category. byroot asked for this. A Dockerfile or buildpack can set BUNDLE_PRUNE=1 without knowing the category names and pick up new categories as they're added.

One thing to watch out for. Only false, f, no, n, 0, and the empty string count as false. This vocabulary is shared by every Bundler setting, so BUNDLE_PRUNE=off and BUNDLE_PRUNE=none are true, which means prune everything.

Pruning runs after a successful bundle install, bundle update, or bundle cache, and during bundle clean.

It needs a bundle path

If you set prune without configuring a bundle path, nothing is deleted and you get only a warning.

The `prune` setting was ignored because this bundle installs into the system gem
directory, which Bundler shares with RubyGems. Run `bundle config set --local
path vendor/bundle` to prune.

In Bundler 4, path is unset by default, and gems go into the system gem directory. Its cache is shared with RubyGems and also holds gem files that gem install put there without Bundler knowing. If prune deleted those, the damage would reach beyond what Bundler manages, so it only runs when a bundle path is set. Once Bundler 5 makes .bundle the default path, this guard will simply stop firing.

Getting things back after pruning

prune only deletes things that can be regenerated, but they don't come back on their own. Pruned artifacts return only when Bundler reinstalls the gem. A plain bundle install fetches nothing for gems that are already installed, so the cache stays empty. Use bundle install --redownload to fetch them again. bundle pristine works once the cache is back. If the prune setting is still there, though, they get deleted again at the end of the reinstall.

`no_prune` is now `keep_outdated_cache`

There's an existing setting with a similar name, no_prune. It controls whether bundle cache removes outdated gems from vendor/cache, and it has nothing to do with the new prune. The name reads as if it disabled the new prune, so ruby/rubygems#9816 renamed it to keep_outdated_cache. The polarity is the same, and true still means keep. The old name is still read, but it prints a deprecation warning.

[DEPRECATED] The `no_prune` setting has been renamed to `keep_outdated_cache` and will be removed in Bundler 5. Use `keep_outdated_cache` instead.

The old name goes away in Bundler 5, so if your config has BUNDLE_NO_PRUNE, update it now.

Try It

Neither override nor prune changes anything just because you upgrade to 4.1. Until now, RubyGems and Bundler decided on their own which constraints to resolve against and which install artifacts to keep. With 4.1, people who need to can make those calls themselves.

4.1.0.beta2 is on rubygems.org, so you can try it today.

gem update --system 4.1.0.beta2
gem install bundler -v 4.1.0.beta2

If anything behaves oddly during the beta, please report it to ruby/rubygems. Parts 2 and 3 will cover the rest of the 4.1 features.

Notes

Written in October 2026 against 4.1.0.beta2. Details may change before the final release.

What Active Rubyists Are Using in 2026: A Maintainer's Read of the RubyKaigi Survey

SHIBATA Hiroshi — Fri, 12 Jun 2026 06:15:43 +0000

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

TL;DR

At RubyKaigi 2026 we ran a 7-question survey on what Ruby developers are actually using: Ruby version, editor, coding agent, version manager, local dev environment. Around 400 responses. The headlines: Ruby 4.0 adoption is already on par with 3.4 less than six months after release, Claude Code is used by around 80% of respondents, VS Code + Cursor dominate the editor space, and mise / asdf are catching up to rbenv. This post walks through the numbers with a maintainer's commentary on each.

About the Data

The survey was collected at the ANDPAD booth at RubyKaigi 2026 (April 2026). Around 400 unique respondents, out of a conference crowd of well over 1,000 attendees. Q1 and Q2 were single-select. Q3 onward allowed multiple selections. Bar heights below represent the absolute number of people choosing each option, not market share. Charts are in Japanese; the bullet list under each chart translates the labels.

This is not a global Ruby survey. RubyKaigi is held in Japan and the audience is Japan-centric, though it includes a significant number of overseas Rubyists who travel in for the conference. Compared to the Stack Overflow Developer Survey, this population skews heavily toward actively-shipping professionals who attend in-person Ruby events. Read it as a snapshot of "Rubyists who still show up in person in 2026," not a representative cross-section of all Ruby users. One more caveat: I maintain several of the tools discussed below, so this is my read of the numbers, not a neutral analysis.

Q1. How Many Years Have You Been Using Ruby?

0–2 years: ~115
3–5 years: ~95
6–9 years: ~65
10+ years: ~100

A U-shaped distribution: newcomers and 10+ year veterans are both large groups, with a thinner middle. Ruby is past 30 years old now, and the fact that both ends of the experience curve are this thick suggests the community is renewing itself while keeping its long-term core intact.

Globally, AI coding tools have made small teams pick Rails again ("let's build it in Rails one more time"), while large-scale users like Shopify and GitHub keep pushing the upper end forward. The "I just started writing Ruby" voices I heard at the booth match the survey shape.

Q2. What Ruby Version Is Your Main Production Project On?

Ruby 3.2 or earlier: ~60
Ruby 3.3: ~50
Ruby 3.4: ~145
Ruby 4.0 (stable): ~140
Ruby 4.1+ (master / dev): ~15

This was the result that surprised me most. Ruby 4.0 was released on December 25, 2025, less than six months before this survey, and it's already on par with 3.4 as the primary production version. As a maintainer team we deliberately kept the 3.x → 4.0 migration cost small even though 4.0 is a major bump, and gem compatibility moved fast. Many projects are already making 4.0 the primary version in CI. That design call appears to be paying off.

A meaningful number of teams are still on 3.3 or earlier, which is the practical reality of long-running services. For context, Ruby ships a new minor version every Christmas, and each series is supported for roughly three years. Ruby 3.2 is already EOL, and Ruby 3.3 moved to security maintenance in March 2026, meaning it receives security fixes only. If you're on either, plan your upgrade to 3.4 or 4.0 within that window. If something specific is blocking the upgrade, we maintainers would love to hear about it.

Q3. What Editors Do You Use at Work?

VS Code: ~200
Cursor: ~110
Neovim / Vim: ~70
RubyMine: ~45
Zed: ~15
Emacs: ~10
Sublime / Cmux / Antigravity / Helix: a handful each
Other: ~10

This is the first multi-select question, so the counts overlap. Some respondents run VS Code alongside Cursor, or pair Neovim with VS Code for completion. Even accounting for that overlap, VS Code is the clear top at ~200, followed by Cursor at ~110.

VS Code has been the top editor in JetBrains' State of Developer Ecosystem and the Stack Overflow Developer Survey for years. What's new in 2026 is the rise of Cursor and Zed. Editor choice is increasingly driven by LSP support (notably ruby-lsp) and the quality of built-in AI assist, rather than by editor traditions.

Q4. What Coding Agent Do You Use at Work?

This was the most skewed result of the entire survey.

Claude Code: ~325
GitHub Copilot (Chat / Autocomplete): ~85
GitHub Copilot Workspace: ~60
Codex: ~25
Not allowed by company policy / not using: ~10
Devin: ~10
Amazon Q Developer / Cline / Roo Code / Gemini / other: a few each

Claude Code at ~325 is roughly 80% of respondents. The takeaway is blunt. If you're using a coding agent in 2026, you're almost certainly using Claude Code. Among Ruby developers attending RubyKaigi, it's the effective default.

The "not allowed by company policy" cluster is small but worth naming. The practical questions are still not fully solved at every org: what code or customer data leaves the company, vendor lock-in, and contract language for LLM-bound data flows. The unglamorous work of "making coding agents usable internally" is going to be a real competitive factor for engineering organizations over the next year.

Q5. What Are You Building with Coding Agents?

Production code at work: ~320
Hobby projects: ~165
Internal tooling at work: ~160
OSS used by your product: ~50
Other OSS: ~35
Other: ~5

Total votes are around 735, which means each respondent uses coding agents for about two categories on average. Production code at ~320 is unsurprising. Essentially everyone using a coding agent is using it at work. What's more interesting is that "hobby projects" (~165) and "internal tooling" (~160) sit at roughly half the production-code volume. For myself, since I started handing maintenance of Ruby-adjacent tools (like all-ruby) and release/packaging scripts to Claude Code, I write less code by hand but ship more.

Combining "OSS used by your product" (~50) and "other OSS" (~35), roughly 85 respondents are bringing coding agents into OSS work. Even after deduplicating, that's around 20% of respondents using coding agents to maintain open source. That would have been hard to imagine a year ago. For the Ruby ecosystem this directly lowers maintenance burden, and I see the effect firsthand on RubyGems and Bundler.

Q6. What Do You Use for Package and Version Management?

Ruby-specific tools like rbenv: ~200
mise / asdf: ~145
Homebrew (project-local): ~140
Dev Containers: ~60
Nix-family (nix / devbox): ~10
Other: ~10

I'm one of the rbenv maintainers, so factor in my bias. Still, the rbenv family is the largest group at ~200, with mise/asdf catching up at ~145. As more developers move between Node.js, Python, Go, and Ruby in the same week, the appeal of "one tool for all languages" instead of "one version manager per language" is real. Some portion of the rbenv user base is clearly in the middle of switching to or co-running mise.

Homebrew (project-local) sits at ~140, the same range as mise/asdf. I suspect this is a signal that more people are running their project Ruby inside Docker or in a remote dev environment and simply don't need to switch versions on the host anymore.

Q7. How Do You Run Your Project Locally?

Docker Compose: ~295
Native (macOS / Linux): ~65
Lima / Colima: ~35
OrbStack: ~30
Kamal (local runner): ~5
Codespaces / cloud IDE: ~5
Podman Desktop: ~5
Other: ~5

Docker Compose at ~295 is roughly three-quarters of respondents. For a Rails app, spinning up web / DB / Redis / job queue together with Docker Compose is effectively the standard local stack.

Lima / Colima at ~35 and OrbStack at ~30 are neck-and-neck for the "Linux containers on Apple Silicon" slot. I'm personally curious how Apple's official container command, introduced in macOS 26, will land here over the next year. Native (macOS / Linux) at ~65 is the segment that runs Ruby / PostgreSQL / Redis directly on the host. It's simpler and noticeably faster than going through a container layer, and I work this way most of the time.

What This Says About Ruby in 2026

Seven questions, and the picture that comes out is a community that's mature but tooling-wise in a very dynamic phase.

Ruby 4.0 adoption is moving faster than expected. Editors are converging on VS Code and Cursor, where AI assist is built in. Coding agents are heavily concentrated on Claude Code. Version managers are diversifying away from rbenv-only toward mise / asdf. Every one of these has shifted noticeably in the last 12–24 months. The actual experience of writing Ruby hasn't really changed in 20 years, but the tooling around it is in the middle of a generational turnover right now.

From the maintainer side, my job is to watch these shifts and keep Ruby and RubyGems / Bundler as the foundation that all this tooling can build on. Supply chain security work, like the cooldown discussion on RubyGems I wrote about earlier this year, is increasingly cross-ecosystem rather than Ruby-only. The maintenance work going forward is to pick Ruby-shaped solutions that fit into the broader picture.

If You Want Global Numbers

This is a Japan-centric snapshot. For a global view, the Rails Developer Survey run by Rails Foundation is the better reference, and Rails Developer Survey 2026 is open for responses right now. The more practitioners like the ones in this survey respond, the more its results reflect what experienced teams are actually doing in production. It takes 10–15 minutes. Please consider filling it out.

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.

DEV Community: SHIBATA Hiroshi

What's New in RubyGems/Bundler 4.1, Part 1: override and prune

TL;DR

override in the Gemfile

When an upper bound gets in your way

Syntax

It reaches transitive dependencies

The lockfile doesn't record override

Ruby and RubyGems version requirements

Dropping or replacing a dependency with from: and to:

prune in Bundler

Turning the Dockerfile rm -rf into a setting

Usage

It needs a bundle path

Getting things back after pruning

no_prune is now keep_outdated_cache

Try It

Notes

What Active Rubyists Are Using in 2026: A Maintainer's Read of the RubyKaigi Survey

TL;DR

About the Data

Q1. How Many Years Have You Been Using Ruby?

Q2. What Ruby Version Is Your Main Production Project On?

Q3. What Editors Do You Use at Work?

Q4. What Coding Agent Do You Use at Work?

Q5. What Are You Building with Coding Agents?

Q6. What Do You Use for Package and Version Management?

Q7. How Do You Run Your Project Locally?

What This Says About Ruby in 2026

If You Want Global Numbers

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

TL;DR

What Happened in March

Ruby's Versioning: Not Quite Semver

The Branch Lifecycle

Who Maintains What

What "Security Maintenance" Actually Means

How a Release Gets Made

What This Means for You

Notes

Should RubyGems/Bundler Have a Cooldown Feature?

TL;DR

What Is a Cooldown?

The Landscape

Dependency Update Tools

Package Managers

Where Does Ruby Stand?

The "guinea pig" problem

Delayed security fixes

The illusion of safety

Buying time for security researchers

What We're Considering

Bundler Cooldown Option

Scanning and Metadata on RubyGems.org

Beyond Cooldown

Conclusion

Notes

`override` in the Gemfile

The lockfile doesn't record `override`

Dropping or replacing a dependency with `from:` and `to:`

`prune` in Bundler

Turning the Dockerfile `rm -rf` into a setting

`no_prune` is now `keep_outdated_cache`