Confusion regarding “Maintenance LTS” status
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
- Documentación
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- node.js
- Área
- documentation, release
Línea de trabajo
Comienza revisando la terminología existente de Maintenance LTS y la discusión de ocho comentarios del issue, incluido el historial del cambio de redacción. Se considera terminado cuando el proyecto acuerde un lenguaje y unas directrices más claros para los desarrolladores de bibliotecas y aplicaciones sobre la migración y el soporte durante esta fase.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I’ve been reading through the history a bit of how “Maintenance” was changed to “Maintenance LTS.” There seems to be good reasoning behind the wording but what I’m finding is that there are some unintended consequences that need to be resolved.
In my view, maintenance means “get off of this.” In fact, it’s my view that it needs to mean that, especially for libraries since they have to move people early in order to push applications to upgrade before the window closes. The end of maintenance means “no more security fixes.” It means “when this is over it’s potentially harmful to run this version.” But that’s not the way people are interpreting it.
Library authors seem to think that they should ensure support in the most recent versions of their libraries until the end of this window. I don’t think that’s the intention, because we need the ecosystem to be migrating away from this version during that maintenance window if we ever hope to have applications and vendors migrated off before the window closes. There’s a limited number of incentives Node.js has to push an ecosystem this large and complex in a more secure direction, and the current wording and lack of clear direction to developers means the few incentives we have aren’t being used very effectively.
It might be worth changing the language here to clarify the desired behavior of library and application developers and potentially re-wording some of these terms.
- Lenguaje dominante
- JavaScript
- Estrellas
- 4.4k
- Forks
- 675
- Merge medio
- 22 h 29 min
- PR fusionados (30 d)
- 1
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 nodejs/Release
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
Release-agenda
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
-
CitGM backlog Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 50/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 20/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 35/100
Todos los issues de nodejs/Release
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
mksglu/context-mode#1200 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
neondatabase/website#5944 ·
-
module: core
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
bigbluebutton/bigbluebutton#25849 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
jaegertracing/jaeger-ui#4506 ·