ruby / ruby/setup-ruby

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

Abierto
#752 12 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
JavaScript
Estrellas
990
Forks
369
Merge medio
18 min
PR fusionados (30 d)
3

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Revisa las exclusiones de versiones en .github/workflows/test.yml y las rutas de soporte de setup-ruby, y compáralas después con la versión del toolcache de ruby-builder descrita en el issue. Confirma si las versiones de MRI, JRuby y TruffleRuby indicadas todavía tienen compilaciones funcionales o usuarios; se considera terminado cuando haya un plan decidido de eliminación o conservación sin romper la interfaz @v1.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
github-actions, javascript, ruby
Área
build-system, ci-cd, release
Tipo de issue
Refactorización
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.