La liberación semántica automatiza todo el flujo de trabajo de lanzamiento del paquete que incluye: determinar el próximo número de versión, generar las notas de versión y publicar el paquete.
Esto elimina la conexión inmediata entre las emociones humanas y los números de versión, siguiendo estrictamente la especificación de versiones semánticas y comunicando el impacto de los cambios a los consumidores.
Confía en nosotros, esto cambiará tu flujo de trabajo para mejor. - Egghead.io
Lanzamiento totalmente automatizado
Hacer cumplir la especificación de versiones semánticas
Nuevas características y correcciones están disponibles de inmediato para los usuarios.
Notificar a los mantenedores y usuarios de nuevos lanzamientos
Use la Convención de mensajes de confirmación formalizada para documentar los cambios en la base de código
Publicar en diferentes canales de distribución (como NPM DIST-Tags) basados en fusiones GIT
Integre con su flujo de trabajo de integración continua
Evite posibles errores asociados con versiones manuales
Admite cualquier gerente de paquetes e idiomas a través de complementos
Configuración simple y reutilizable a través de configuraciones compartibles
Soporte para la procedencia del paquete NPM que promueve una mayor seguridad de la cadena de suministro a través de certificaciones firmadas sobre las acciones de GitHub
La liberación semántica utiliza los mensajes de confirmación para determinar el impacto del consumidor de los cambios en la base de código. Después de las convenciones formalizadas para los mensajes de confirmación, la liberación semántica determina automáticamente el próximo número de versión semántica, genera un ChangeLog y publica la versión.
Por defecto, la liberación semántica utiliza convenciones de mensajes de confirmación angular. El formato de mensaje de confirmación se puede cambiar con las opciones preset
o config
de los complementos de @semánticos-releing/commit-analyzer y @semántico-releing/libe-notes-generator.
Las herramientas como Commitizen o Compromlint pueden usarse para ayudar a los contribuyentes y hacer cumplir los mensajes de confirmación válidos.
La siguiente tabla muestra qué mensaje de confirmación le da qué tipo de liberación cuando se ejecuta semantic-release
(usando la configuración predeterminada):
Mensaje de compromiso | Tipo de liberación |
---|---|
fix(pencil): stop graphite breaking when too much pressure applied | Patch Fix Release |
feat(pencil): add 'graphiteWidth' option | Lanzamiento de características menores |
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons. | Lanzamiento de ruptura mayor (Tenga en cuenta que el BREAKING CHANGE: el token debe estar en el pie de página de la confirmación) |
La liberación semántica está destinada a ejecutarse en el entorno CI después de cada construcción exitosa en la rama de lanzamiento. De esta manera, ningún humano está directamente involucrado en el proceso de liberación y se garantiza que los lanzamientos no son románticos y poco sentimentales.
Para cada nuevo compromiso agregado a una de las ramas de lanzamiento (por ejemplo: master
, main
, next
, beta
), con git push
o fusionando una solicitud de extracción o fusionando de otra rama, una compilación de CI se activa y ejecuta la semantic-release
Comando para realizar una versión si hay cambios en la base de código desde la última versión que afectan las funcionalidades del paquete.
La liberación semántica ofrece varias formas de controlar el momento, el contenido y la audiencia de los lanzamientos publicados. Vea los flujos de trabajo de ejemplo en las siguientes recetas:
Usando canales de distribución
Lanzamientos de mantenimiento
Prerelestratos
Después de ejecutar las pruebas, el comando semantic-release
ejecutará los siguientes pasos:
Paso | Descripción |
---|---|
Verificar condiciones | Verifique todas las condiciones para proceder con la liberación. |
Obtener el último lanzamiento | Obtenga la confirmación correspondiente a la última versión analizando las etiquetas GIT. |
Analizar los compromisos | Determine el tipo de liberación basado en los compromisos agregados desde la última versión. |
Verificar el lanzamiento | Verifique la conformidad de la liberación. |
Generar notas | Genere las notas de versión para los compromisos agregados desde la última versión. |
Crear etiqueta Git | Cree una etiqueta GIT correspondiente a la nueva versión de lanzamiento. |
Preparar | Prepare el lanzamiento. |
Publicar | Publique el lanzamiento. |
Notificar | Notificar nuevos lanzamientos o errores. |
Para usar liberación semántica, necesita:
Para alojar su código en un repositorio de git
Utilice un servicio de integración continua que le permita configurar credenciales de forma segura
Una versión Git CLI que cumple con nuestro requisito de versión instalado en su entorno de integración continua
Una versión node.js que cumple con nuestro requisito de versión instalado en su entorno de integración continua
Uso
Empezando
Instalación
Configuración de CI
Configuración
Complementos
Configuración de flujo de trabajo
Configuraciones compartibles
Extensión
Complementos
Configuración compartible
Recetas
Configuraciones de CI
Git Servicios alojados
Liberación de flujo de trabajo
Guía de desarrolladores
API JavaScript
Desarrollo de complementos
Desarrollo de configuración compartible
Apoyo
Recursos
Preguntas frecuentes
Solución de problemas
Requisito de la versión de nodo
Política de soporte de nodo
Discusiones de Github
Desbordamiento de la pila
Gorjeo
Informe a la gente que su paquete se publica con liberación semántica y que la convención de comodidad es seguida por la inclusión de esta insignia en su readme.
/ /liberación semántica)
![]() | ![]() | ![]() |
---|---|---|
Gregor Martynus | Pierre Vanduynslager | Matt Travi |
![]() | ![]() | ![]() | ![]() | ![]() |
---|---|---|---|---|
Stephan Bönnemann | Rolf Erik Lekang | Johannes Jörg Schmidt | Finlandés pauls | Christoph Witzko |