Support prerelease versions for all tools
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, nodejs, typescript
- Área
- build-system, devops, release, tooling
Línea de trabajo
This is a cross-cutting design issue spanning several components: tool-versions, the binary-builder in internal-tools, the node-prebuild and maven-prebuild projects, each builder.json, and the CLI's version resolution. Start by reading how the CLI resolves latest and partial versions, then how tool-versions publishes releases. Done would mean an exact prerelease installs while latest still resolves to stable, which needs maintainer agreement on scope first.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Exact prerelease versions should be installable for every tool, from the data and from the prebuilds. latest and partial versions keep resolving to stable releases only.
- tool-versions: publishes prereleases with
prerelease: true(from the GitHub flag or the versioning); maven gets the Apache distributions incl. prereleases. - internal-tools
binary-builder: build upstream prereleases and publish them as GitHub prereleases (prerelease: true),lateststays on stable releases. - node-prebuild: build the Node 27 alphas (
27.0.0-alpha.0.0.0is innodejs.org/dist/index.json), see #6157. - maven-prebuild: build the maven 4 prereleases (
-alpha-,-beta-,-rc-). - other prebuilds: check each
builder.jsonand version check when they need prereleases. - CLI: never pick a prerelease for
latestor a partial version, but install an exact prerelease from the data.
Drafted by Claude Code (Claude Opus 5.5).
- Lenguaje dominante
- TypeScript
- Estrellas
- 58
- Forks
- 65
- Merge medio
- 6 h 47 min
- PR fusionados (30 d)
- 504
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin 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 containerbase/base
-
Stop installing bzr for golangAbiertobreaking
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
containerbase/base#8022 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
containerbase/base#7891 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
containerbase/base#7842 ·
Los mantenedores suelen responder en 1 día
-
priority-3-normal tool/dotnet
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
containerbase/base#5996 ·
Los mantenedores suelen responder en 1 día
-
New tool: JuliaPosiblemente ocupada @stemann la tomó hoy. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 66/100
containerbase/base#8213 ·
Los mantenedores suelen responder en 1 día
Todos los issues de containerbase/base
Issues similares
-
test-reliability
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Azure/azure-sdk-for-js#40672 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
HarperFast/studio#2067 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
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
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
liberation-data/drivine#639 · 2 comentarios ·
Los mantenedores suelen responder en 1 día