Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
#752 12 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
github-actions, javascript, ruby
Bereich
build-system, ci-cd, release

Rechercherichtung

Überprüfe die Versionsausschlüsse in .github/workflows/test.yml und die setup-ruby-Supportpfade und vergleiche sie anschließend mit dem im Issue beschriebenen ruby-builder-Toolcache-Release. Bestätige, ob die aufgeführten MRI-, JRuby- und TruffleRuby-Versionen noch funktionierende Builds oder Nutzer haben; abgeschlossen ist die Aufgabe mit einem festgelegten Entfernungs- oder Beibehaltungsplan, ohne die @v1-Schnittstelle zu beschädigen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
JavaScript
Sterne
990
Forks
369
Ø Merge
18 Min.
Gemergte PRs (30 T.)
3

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ruby/setup-ruby

Alle Issues in ruby/setup-ruby

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.