El mantenimiento de paquetes comprueba que el paquete publicado de un proyecto esté al día, sea resoluble y no esté marcado como obsoleto en su registro. El cuidado del registro es distinto de la actividad en GitHub: una biblioteca puede quedarse desactualizada — o marcarse explícitamente como abandonada — en npm o Packagist mientras su repositorio sigue recibiendo commits, y los usuarios instalan el paquete, no el repositorio.
- Categoría: Sostenibilidad y Gobernanza (20% dentro de la categoría)
- Peso en el índice general: 4,8%
- Clave de la métrica:
package_maintenance - Se aplica a: repositorios que publican al menos un paquete; en caso contrario,
null
Cómo se calcula el valor
| Componente | Peso | Criterios |
|---|---|---|
| Publicado y resoluble | 25 | al menos uno de los paquetes del repositorio se resuelve en su registro |
| Recencia de publicación | 35 | última publicación ≤180 días → 35 pts, ≤365 → 26, ≤730 → 14, más antigua → 4 |
| Historial de versiones | 20 | ≥5 versiones publicadas → 20, ≥2 → 12, en otro caso 4 |
| No obsoleto | 20 | última versión deprecated (npm), abandoned (Packagist) o yanked → 0; en otro caso 20 |
Por qué importa cada componente
- Resoluble es la base: el paquete se instala desde el registro al que un usuario acudiría realmente.
- La recencia de publicación detecta el fallo silencioso en el que las correcciones llegan al repositorio pero nunca se distribuyen — la copia del registro envejece discretamente mientras el repositorio parece vivo.
- El historial de versiones distingue una línea de versiones mantenida de una publicación única.
- La obsolescencia es la señal más contundente del propio registro, establecida por los propios mantenedores; una última versión marcada como obsoleta anula el componente por completo.
Cómo interpretar el resultado
- Conviene leerla junto con la disciplina de publicación: las releases de GitHub y las publicaciones en el registro suelen moverse a la par, y la divergencia entre ambas es en sí misma informativa.
- Solo se cuentan los paquetes cuyos metadatos de registro apuntan de forma verificable al repositorio inspeccionado — véase ecosistemas compatibles para la regla de correspondencia.
- Los repositorios que no publican paquetes son
nullaquí y su categoría se renormaliza — nunca una penalización por ser una aplicación.
Cómo mejorar el valor
- Publicar las versiones en el registro como parte del proceso de release, no como una ocurrencia tardía.
- Mantener al menos una cadencia de publicación anual para los paquetes mantenidos — incluso una versión de parche restablece la recencia.
- No dejar nunca una versión obsoleta o retirada (yanked) como la más reciente; publicar una sucesora o retirar la marca.
Relacionado: adopción en el ecosistema · disciplina de publicación