ruby / ruby/setup-ruby

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.

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

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.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

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.

Bewertung

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

Neue Issues direkt in Ihr Postfach

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