DEV Community: SHIBATA Hiroshi

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.