Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Remove limitation on the frequency of semver-minor LTS relesease

Abierto
#772 13 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
nodejs
Área
release

Línea de trabajo

Comienza revisando el flujo de trabajo de release de LTS y la discusión de este issue, centrándote en cómo pasan los cambios semver-patch y semver-minor de main a la rama LTS. Examina las etiquetas dont-land, backport-blocked y backport-requested. Se considera terminado cuando la regla de frecuencia de releases tiene una decisión documentada y la guía de releases la refleja.

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

Descripción

I'd like to propose we remove the unofficial rule we have limiting the frequency of semver-minor LTS releases to one per quarter (I think?). Having prepared some of those releases, I think the rule is counterproductive, error-prone, and puts a huge burden on the releasers. Here are a few reasons I would like to remove the rule and let the releaser decide each time whether they are going to prepare a minor or a patch release:

  • The main branch is not managed in a way that facilitates our work. Once a few semver-minor changes have landed, a lot of subsequent semver-patch changes will depend on them, making it difficult to find commits that can land cleanly on the LTS branch. The consequence of this is that we tend to have relatively small patch releases followed by a huge minor release like v16.17.0 today.
  • Because most of the semver-patch commits cannot land cleanly without their semver-minor dependencies, the release preparation takes a very long time as the releaser has to check for each conflicting commit why it doesn't apply. Then they either add the appropriate label (dont-land, backport-blocked, backport-requested) or fix the conflict manually. Each manual fix takes time and may introduce bugs even if it seems trivial.
  • Users have to wait many months for changes they care about (many of these changes being semver-patch bug fixes) to land on LTS.

@nodejs/lts

Lenguaje dominante
JavaScript
Estrellas
4.4k
Forks
675
Merge medio
22 h 29 min
PR fusionados (30 d)
1

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.

Más de nodejs/Release

Todos los issues de nodejs/Release

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.