Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Removing old Ruby builds like Ruby 1.9-2.2 and JRuby 9.1-9.3 and TruffleRuby 19-22

Open
#752 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Stale
Tech stack
github-actions, javascript, ruby
Domain
build-system, ci-cd, release

Research direction

Review the version excludes in .github/workflows/test.yml and the setup-ruby support paths, then compare them with the ruby-builder toolcache release described in the issue. Confirm whether the listed MRI, JRuby, and TruffleRuby versions still have working builds or users; done means a decided removal or retention plan without breaking the @v1 interface.

Written by the indexing model from the issue text.

Description

Based on the excludes in https://github.com/ruby/setup-ruby/blob/afda160499b3ea79ea34ed7dc1191c3f68294309/.github/workflows/test.yml#L38
I'm thinking to remove old Rubies such as:

  • 1.9. which is only built on ubuntu-22.04 and macos-latest but fails to build on all other platforms. It probably doesn't work well either and there are tons of exclude for it.
  • 2.0, 2.1 and 2.2 since 2.2 is known to segfault (https://github.com/ruby/setup-ruby/issues/496) and likely none of them work well. Also 2.2 has this weird version mismatch explained in the README. Also the oldest version that builds on arm64 is 2.3.5 and it seems nice to have approximately the same versions on x64 and arm64 available (when possible).
  • JRuby 9.1, 9.2 and 9.3, so we'd keep only supported release trains of 9.4 and 10.0.
  • TruffleRuby releases which are EOL and older than 2 years, like everything older than 23.0.0 (which is compat 3.1, 22.3 is compat 3.0).

I want to keep @v1 and avoid jumping to @v2 to avoid unnecessary churn and confusion. The idea is to not maintain those anymore, if there was a @v2, @v1 would become "dead" and I don't want that and all the issue spam that would result from it.

I'm thinking to first remove support for them in setup-ruby (so it would result in an error then, or maybe at first a warning), and then after some time remove them in https://github.com/ruby/ruby-builder/releases/tag/toolcache.

Is anyone using those versions and have a working build they can link?
That would make me consider keeping some of these versions longer.

Dominant language
JavaScript
Stars
990
Forks
369
Avg merge
18m
Merged PRs (30d)
3

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ruby/setup-ruby

All issues in ruby/setup-ruby

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.