Require API version-bump checks after the bootstrap release
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Empieza en .github/workflows/release.yml:132-143 e inspecciona la comprobación existente del bump del paquete, el comentario de bootstrap y las condiciones de release. Determina cómo se representan la excepción de bootstrap y los casos stable, release-candidate y pre-release. Se considera terminado cuando las versiones stable posteriores requieren un bump de API suficiente, los diagnósticos muestran el bump requerido y el comportamiento está documentado y probado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
The release workflow currently runs the package bump check with:
bump_check: warn
at .github/workflows/release.yml:132-143.
The comment explains a valid bootstrap exception: the previous stable 0.20.0 bundle and alpha-0 are no longer parseable by the new compiler. It also says to change the check to require after the first stable new-compiler .tar.zst release.
Leaving this as a comment-only follow-up makes it easy for later releases to continue publishing despite an incorrect semantic version bump.
Suggested direction
After the first stable new-compiler release is available and parseable, change bump_check to require. If possible, make the transition version-aware so the exception automatically expires after the bootstrap version rather than relying on a later manual edit.
Acceptance criteria
- The bootstrap exception is limited to the specific release(s) that need it.
- All subsequent stable releases fail before publication when the API bump is insufficient.
- Release-candidate and pre-release behavior is documented and tested.
- The workflow emits a clear diagnostic containing the detected required bump.
- The obsolete bootstrap comment is removed or updated once enforcement is active.
- Lenguaje dominante
- Rust
- Estrellas
- 121
- Forks
- 45
- Merge medio
- 19 h 1 min
- PR fusionados (30 d)
- 16
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de roc-lang/basic-cli
-
Unix socket supportAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
roc-lang/basic-cli#455 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de roc-lang/basic-cli
Issues similares
-
chore P0
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Liquid glass draws square corners on undecorated windows (cornerRadius without clipsToBounds)Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
tauri-apps/window-vibrancy#230 ·
-
area:release bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
registrystack/registry-stack#1874 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100