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

[eregon]

Based on the excludes in

setup-ruby/.github/workflows/test.yml

Line 38 in afda160

exclude:

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 (Bundler install appears broken on Ruby 2.2 #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.

[eregon]

Also potentially removing all previews and RCs (except 3.5.0-preview1 since 3.5.0 is not out yet) since those seem useless once the real corresponding release is out (i.e., nobody should use a preview/RC when the corresponding release is out).

[eregon]

Maybe the rule to be simpler should be "remove every EOL Ruby" which would almost match the above but also include Ruby 2.3 - 3.1 (which is maybe too aggressive).
That's using the EOL definition from the Ruby implementation support, i.e. CRuby support 3.2+ currently.
Some Linux distributions might claim to support Ruby 3.1 etc longer, though AFAIK they don't really support it, just they don't remove it from that distro version (and maybe fix the most obvious security issues).

[ntkme]

I agree with dropping EOL rubies without bumping the major version of the action.

We should emit a warning for at least one month before actually dropping the support:
https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-warning-message

There are also users who pin the action down to a specific commit sha that will not receive any warnings. E.g. GitHub provides templates that’s pinned to a random commit by default in starter workflow (the template options users get when clicking “new workflow” from Actions tab on UI): https://github.com/search?q=repo%3Aactions%2Fstarter-workflows+ruby%2Fsetup-ruby%40&type=code

Therefore, it’s probably better just leave the toolcache archives for old rubies as is and only drop support in this action itself.

[dentarg]

What's the reason for removing old Rubies?

I mean, once built, they wont stop working until the OS version disappears? Is it because users expect the very old Rubies to work on newer OSes when they can't?

Here's some usage of old Rubies

• Sequel: CI workflow, required_ruby_version >= 1.9.2
• Addressable: CI workflow, required_ruby_version>= 2.2

I do understand we really want to spend none/minimal effort on these old Rubies, but removing them will cause disruptions.

[dentarg]

Puma still has required_ruby_version >= 2.4. (It has been suggested to raise it considerably)

[eregon]

What's the reason for removing old Rubies?

• Removing known broken builds like 2.2 and other old suspected-(partially maybe)-broken builds.
• 1.9 is only built on very few images, that seems confusing, I'd rather make it clear it's just not available at all.
• For future platforms I want to not try building old Rubies like 2.2 and older (and similar for old JRuby/TruffleRuby versions). CRuby <= 2.2 already fails to build on any aarch64 platform, but I'd like to be consistent and not try on other architectures either.
• It'd be nice to simplify at some point to "no more <= 2.2 available, 2.3 is minimum for all". Makes it clearer what's available in the README and to users, much closer to the full combination of versions & platforms being supported, less CI jobs, likely some code simplifications (notably Bundler 2 requires Ruby 2.3+), etc.
• At some point we might hit a limit to the number of assets in the ruby-builder release.

Here's some usage of old Rubies

Thanks.

• Sequel: CI workflow, required_ruby_version >= 1.9.2

Interesting, 2.2 is not there (makes sense since it's broken) and 1.9 only on 22.04.
It seems the 1.9, 2.0 and 2.1 builds work fine in those jobs.

• Addressable: CI workflow, required_ruby_version>= 2.2

This also skips 2.2.
Maybe we should just remove 2.2 from the list of supported versions but then it's a bit weird to have such a hole in the middle of other versions, hence why it seems nicer to just remove <= 2.2.

[eregon]

Uploading new releases now gives:
https://github.com/ruby/ruby-builder/actions/runs/17772707458/job/50512700348

Run gh release upload "toolcache" "truffleruby+graalvm-25.0.0-macos-13-arm64.tar.gz"
HTTP 422: Validation Failed (https://uploads.github.com/repos/ruby/ruby-builder/releases/33599578/assets?label=&name=truffleruby%2Bgraalvm-25.0.0-macos-13-arm64.tar.gz)
file_count limited to 1000 assets per release

So this is becoming pretty urgent.

(we could also try to use separate releases but that's likely a lot of work and I don't have much time for it, also it becomes harder to see the full releases list then and what's built)

[ntkme]

use separate releases but that's likely a lot of work and I don't have much time for it

This should be pretty easy:

1. Change the ruby-builder to create new release and upload to "version" tags (e.g. ruby-3.4.6, jruby-10.0.2.0)
2. Write an one-time script to download and re-upload existing release assets to "version" tag - a small shell script using jq and gh command will do. We can submit the script as a PR and run it inside github actions for transparency and avoid permission issue as a contributor.
3. Change the setup-ruby action to use "version" tags in the download url instead of "latest"

I can take a look soon when I get a chance.

harder to see the full releases list

Funny enough that the Rest API v3 can only list first 1000 releases, too... However, we can use git to list all tags, and use gh to query artifacts for each release:

git ls-remote --tags https://github.com/ruby/ruby-builder.git | cut -d '/' -f 3 | xargs -n 1 -- gh release view --json assets --repo ruby/ruby-builder | jq '.assets[].name'

[eregon]

Also potentially removing all previews and RCs (except 3.5.0-preview1 since 3.5.0 is not out yet) since those seem useless once the real corresponding release is out (i.e., nobody should use a preview/RC when the corresponding release is out).

I have done that now to get some headroom.

[eregon]

@ntkme Yes, that seems a simple-ish way, however it then loses the ability to version per "kind of builds", for example in the past we have tried:

• --enable-shared vs not
• --enable-load-relative vs not
• Builds in $RUNNER_TOOL_CACHE (which the current tag reflects) vs somewhere else like ~/.rubies
• Build against openssl3 explicitly, or openssl1.1 explicitly or embed openssl with ruby-build

Currently we use --enable-shared and we don't use --enable-load-relative.
The first is unlikely the change, the second might, but would only work on more recent Rubies.
It would be safer to keep this ability, any idea how to retain that?
I suppose a suffix to the tag or so could work.

[eregon]

One more thought is we could use the downloads stats to find out little-used builds: https://tooomm.github.io/github-release-stats/?username=ruby&repository=ruby-builder
99 are Downloaded 0 times, many seem cases of a new runner (ubuntu-*-arm64) and not the latest X.Y release.
So probably we should only add the latest release per release branch for new runners going forward.