Nyx

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Analiza historial y configuración para inferir cambios y generar información de release. Puede aplicar convenciones como Conventional Commits en distintos ecosistemas.

Ejemplo de uso

Definir cómo cambios fix, feat e incompatibles afectan la versión. La pipeline propone el resultado y las notas antes de publicar artefactos y etiquetas.

Del commit a la versión

Con Conventional Commits cada mensaje declara el tipo de cambio, y Nyx calcula la siguiente versión semántica:

Commit	Efecto en la versión 1.4.2
fix(pagos): redondeo de intereses	1.4.3 (patch)
feat(solicitudes): carga de cédula por foto	1.5.0 (minor)
feat!: elimina el endpoint v1 de consultas	2.0.0 (major)
chore: actualiza dependencias de CI	Sin release

El pie BREAKING CHANGE: en el cuerpo del commit también marca un cambio incompatible.

Comandos y fases

Comando	Qué hace
infer	Lee el historial y calcula la versión, sin modificar nada
make	Genera artefactos locales, como el changelog
mark	Crea el commit, la etiqueta y hace push
publish	Publica la release en GitHub o GitLab

Cada comando ejecuta los anteriores que necesite, y el modo dry run permite ver el resultado sin efectos. Está disponible como CLI, plugin de Gradle y GitHub Action, por lo que no depende del lenguaje del proyecto.

Configuración

La configuración vive en .nyx.yaml (o JSON) e incluye presets para empezar rápido. Los release types definen reglas distintas por rama: versiones definitivas en main, prereleases en ramas de integración (1.5.0-rc.3), versiones internas con metadatos en ramas de feature. Revisa la referencia de configuración para la versión que instales.

Nyx frente a alternativas

Herramienta	Encaja cuando
semantic-release	Ecosistema Node, gran cantidad de plugins
release-please	Flujo basado en un PR de release que se revisa y se fusiona
Changesets	Monorepos JS donde cada PR declara explícitamente su cambio
Nyx	Proyectos políglotas o JVM, configuración declarativa y varias ramas

Buenas prácticas

• Valida el formato de los mensajes con un hook commit-msg (pre-commit hooks) o en el PR.
• Con squash merge, el título del PR se convierte en el commit: valida el título.
• Clona con historial completo en CI (fetch-depth: 0); con un clon superficial no se puede inferir la versión.

Criterios de implementación

Probar primero en modo de inspección y asegurar acceso al historial necesario. Automatizar versiones no resuelve integraciones tardías ni conflictos de ramas prolongadas.