Ruby has released a new minor version every December since 2013, and maintains each branch for a little over three years afterwards. Those two facts between them answer most questions about which version a project should be running, because they mean the answer changes on a predictable schedule rather than when somebody decides to announce something.
Release timeline
15 branches listed, from 1.8.7 (2008-06) to 3.4 (2024-12).
| Version | Released | Maintenance | What changed |
|---|---|---|---|
| 3.4 | 2024-12 | 2028-03 | Prism becomes the default parser. |
| 3.3 | 2023-12 | 2027-03 | YJIT faster again, and a new pure-Ruby JIT to experiment with. |
| 3.2 | 2022-12 | 2026-03 | YJIT becomes usable in production; WASI support. |
| 3.1 | 2021-12 | 2025-03 | YJIT arrives; the hash shorthand. |
| 3.0 | 2020-12 | 2024-04 | Ractors, Fiber scheduler, and RBS ships with the language. |
| 2.7 | 2019-12 | 2023-03 | Pattern matching as an experiment; the keyword-argument warnings. |
| 2.6 | 2018-12 | 2022-04 | A first JIT, off by default, and endless ranges. |
| 2.5 | 2017-12 | 2021-03 | rescue and ensure allowed directly inside blocks. |
| 2.4 | 2016-12 | 2020-04 | Integer unification; Fixnum and Bignum merged. |
| 2.3 | 2015-12 | 2019-03 | The safe navigation operator and frozen string literals. |
| 2.2 | 2014-12 | 2018-03 | Symbol garbage collection, which quietly fixed a leak class. |
| 2.1 | 2013-12 | 2017-04 | Required keyword arguments; the December cadence begins. |
| 2.0.0 | 2013-02 | 2016-02 | Keyword arguments and refinements arrive. |
| 1.9.3 | 2011-10 | 2015-02 | New VM and real encoding support. The hard migration. |
| 1.8.7 | 2008-06 | 2013-06 | The version a whole generation of Rails ran on. |
How the release cycle works
A minor version each December, a patch level whenever a fix warrants one, and maintenance for roughly three years and three months. The December date is a deliberate convention rather than a coincidence, and it makes planning straightforward: a version released this Christmas will stop receiving fixes in the spring three years later.
What maintenance means in practice is two phases. A branch first receives ordinary bug fixes, then moves to security fixes only, then stops. A project sitting on a branch in its security-only phase is not in trouble, but it is on a clock that is already visible.
The chart marks an expected end date differently from an announced one, because the far end of the timeline is a convention rather than a promise. Anything a year or two out should be read as the pattern continuing, not as a commitment.
Which version a project should be on
One of the branches still receiving fixes, and preferably not the newest of them. The version released last December works, and the one before it has had a year of patch releases and a year of gems catching up with it, which for most applications is the better trade.
The newest release is rarely the right one. The one before it usually is.
The exception is a new project, which should start on the newest, because the cost of being early is lowest when there is nothing to migrate and no dependency that has not been chosen yet.
Running an end-of-life branch is a decision rather than an oversight, and it is a defensible one for a short period. What makes it indefensible is not having a date by which it stops, because the gap only ever grows and each year of delay makes the eventual jump larger.
The upgrades that were actually hard
Most Ruby upgrades are uneventful. Three were not, and they are worth knowing about because they are still met in older codebases.
1.8 to 1.9. A new virtual machine and real string encodings. Strings stopped being byte arrays that behaved like text, which broke a great deal of code that had been quietly wrong about encoding for years.
2.7 to 3.0. The separation of positional and keyword arguments, warned about throughout 2.7 and enforced in 3.0. The warnings were the migration path, and projects that had silenced their warnings discovered the work all at once.
Anything crossing a Rails major at the same time. Not a Ruby problem, but the usual cause of a bad upgrade: two moving targets, and no way to tell which one broke a test. Doing them one at a time takes longer and finishes sooner.
How to move between versions
Change one number, run the tests, read the deprecation warnings rather than silencing them. The warnings emitted by the version currently in use are, almost always, the exact list of work required by the next one, which is the whole reason 2.7 emitted so many.
Dependencies are the other half, and usually the larger one. A gem that has not been released in several years will eventually fail to build against a newer Ruby, and that is a dependency decision rather than a language one. It is covered on gems and Bundler.
A version manager is not optional for anybody working across more than one project. Which one matters far less than having one, and having several installed at once through different package managers is the reliable way to spend an afternoon on something that is not programming.
Reading the chart
Each row is one branch, drawn from the month it was released to the month its maintenance ended or is expected to. The vertical line is today, so the rows crossing it are the branches still receiving fixes. That state is worked out when the page is opened rather than written into it, which is the only way a page like this stays true.
The right-hand column names the change that mattered in each release rather than listing everything in it. For the tooling that reads code written in any of these versions, see static analysis tools; for the framework whose own version matrix has to line up with this one, Rails; and for the rest, the section index.
Questions
How often does Ruby release a new version?
A minor version every December since 2013, with patch releases in between as fixes warrant them. The December cadence is a deliberate convention, which is what makes planning an upgrade schedule straightforward.
How long is a Ruby version supported?
Roughly three years and three months from release, in two phases: ordinary bug fixes first, then security fixes only, then nothing. A branch in its security-only phase is not in trouble, but it is on a clock that is already visible.
Which version should a project run?
One still receiving fixes, and usually not the newest. The version before the current one has had a year of patch releases and a year of gems catching up, which suits most applications better. A brand-new project is the exception and should start on the newest.
Which Ruby upgrades were genuinely difficult?
1.8 to 1.9, for the new virtual machine and real string encodings, and 2.7 to 3.0 for the separation of positional and keyword arguments. The third common source of pain is not Ruby at all: crossing a Rails major version at the same time.
What is the best way to prepare for an upgrade?
Read the deprecation warnings from the version currently in use instead of silencing them. They are, almost always, the exact list of work the next version will require, which is why 2.7 emitted so many of them before 3.0 enforced the change.