Herramientas CI/CD
Pega tus commits, indica la versión actual, y obtén una propuesta de versión, un borrador de changelog y un número de build.
Los commits y el número de versión se analizan en tu navegador. No se sube nada, y nunca se llama a ningún servicio de Git o CI.
Pega tus commits o escribe una versión para empezar.
Las líneas no reconocidas nunca bloquean el cálculo; esta opción solo decide si aparecen en la sección «Other» del borrador de changelog.
Pega tus commits o escribe una versión para empezar.
Antes de etiquetar un release normalmente hay que responder a mano tres preguntas: cuál es el siguiente número de versión, qué va en el changelog y qué número de build acompaña a ese release. Esta calculadora de versión de lanzamiento permite generar changelog desde commits usando el mismo lote de commits, calculando a la vez la propuesta de versión y el número de build, para que los tres nunca se desincronicen.
Se diferencia de subir la versión a mano o copiar líneas en CHANGELOG.md en que cada sugerencia viene de analizar la cabecera de cada commit con la misma gramática que nuestro Conventional Commit Builder, no de adivinar un diff ni de llamar a una IA. Nada de lo que pegas sale del navegador, y la herramienta nunca crea una etiqueta, hace push ni llama a ninguna API de Git o CI — solo genera texto para que lo uses tú.
Lo que cambia cuando la versión, el changelog y el número de build salen de los mismos commits.
Algunas calculadoras de release semántica te piden describir los cambios en texto libre y lo envían a una IA que adivina el salto de versión. Esta herramienta en cambio analiza cada cabecera de commit con la misma gramática que nuestro Conventional Commit Builder — la misma entrada siempre da la misma propuesta, y nunca se envía ninguna solicitud de red.
Una calculadora de versión, un generador de changelog y un generador de número de build independientes no conocen el resultado del otro. Aquí la versión propuesta alimenta directamente el título del changelog y el marcador {version} de tu plantilla de número de build, así que los tres se mantienen sincronizados. El changelog generado también funciona como generador de notas de versión listas para publicar.
En cuanto se genera el release, el panel de resultados enlaza directamente con nuestra herramienta ENV diff para comparar variables de entorno antes de desplegar — un paso que no ofrecían los generadores independientes de changelog y número de build que comparamos.
Lo que conviene saber antes de pegar tu primer lote de commits.
Pega las líneas tal como las imprime `git log --pretty=format:%s` — un `type(scope)!: subject` por línea. Los mensajes de varias líneas con cuerpo o pie `BREAKING CHANGE:` no se analizan aquí; marca los cambios incompatibles con `!` justo después del tipo o el alcance.
Escribe la versión actual en formato SemVer estricto (por ejemplo 1.4.2) y edita la plantilla del número de build si hace falta. La plantilla por defecto `{version}+{yyyyMMdd}.{count}` usa la versión propuesta, la fecha de hoy y un contador de build que escribes tú mismo — la herramienta no tiene contexto de CI del que leer un número de build real.
Desactiva la generación automática para editar varios campos antes de recalcular, y luego pulsa Ctrl/Cmd+Intro para ejecutar una vez de forma manual.
La insignia (mayor, menor, parche o sin cambios) muestra qué commit forzó el salto de versión — un marcador de cambio incompatible siempre gana sobre un simple feat o fix. Copia o descarga el changelog, copia el número de build, o sigue el enlace a ENV diff antes de etiquetar el release.
Cualquier cambio en las entradas atenúa el resultado anterior y deshabilita copiar y descargar hasta que vuelvas a generar.
Ver qué no se analizaCuatro piezas que convierten un lote de cabeceras de commit en un borrador de release listo para usar.
Esta herramienta lee líneas `type(scope)!: subject` con la misma gramática que nuestro Conventional Commit Builder, clasifica el impacto de cada línea reconocida y se queda con el más alto — un solo `!` o un solo `feat` en el lote basta para elevar todo el release.
Los commits reconocidos se agrupan en Breaking Changes, Features, Fixes y Other, renderizados como Markdown que puedes copiar o descargar como CHANGELOG.md — las entradas incompatibles siempre aparecen primero.
Combina `{version}`, `{yyyy}`, `{yyyyMM}`, `{yyyyMMdd}` y un `{count}` escrito a mano para obtener el formato de número de build que necesite tu pipeline; los marcadores desconocidos se dejan tal cual y se avisan, en lugar de desaparecer en silencio.
Una línea que no es una cabecera de commit válida se salta en la propuesta de versión y se cuenta aparte, sin detener el cálculo completo — desactiva «ignorar» para verla igualmente en la sección Other del changelog.
Los casos límite que conviene conocer antes de pegar los commits de un release real.
Respuestas a lo que la gente pregunta de verdad antes de confiar en una propuesta de versión basada en commits.
Comprueba que la línea coincide exactamente con `type(scope)!: subject` — falta de dos puntos, un espacio de más o una sintaxis no soportada hacen que toda la línea quede sin reconocer, y una línea no reconocida nunca aporta a la propuesta de versión. El número de líneas reconocidas bajo el resultado muestra cuántas líneas se analizaron realmente.
Edita la plantilla del número de build en Opciones. La plantilla por defecto `{version}+{yyyyMMdd}.{count}` inserta la versión que propone esta herramienta, la fecha de hoy y un contador que escribes tú — aquí no hay ningún entorno de CI del que leer un número de build real, así que `{count}` sigue siendo manual.
El número de versión (como 1.5.0) sigue el versionado semántico y lo determina el impacto de tus commits. El número de build es una cadena distinta generada a partir de una plantilla, útil para sistemas de CI que necesitan distinguir cada build aunque el número de versión no cambie — puede incluir esa misma versión mediante `{version}`, además de una fecha y un `{count}` escrito a mano.
Basta con pegar los commits como una cabecera por línea: esta herramienta va a generar changelog desde commits, agrupados por feat, fix y cambios incompatibles, en formato Keep a Changelog. Cópialo o descárgalo como CHANGELOG.md en lugar de copiarlo a mano.
Una línea que no coincide con `type(scope)!: subject` simplemente se cuenta como «no reconocida» y no entra en el cálculo de la propuesta de versión. Por defecto, «ignorar líneas no reconocidas» está activado, así que tampoco aparece en el borrador de changelog — desactiva esta opción si quieres verla.
¿No encontraste tu respuesta?
Pega tus commits, confirma la versión actual, y en segundos tendrás una propuesta de versión, un borrador de changelog y un número de build.
Todo se ejecuta localmente en tu navegador — sin registro, sin subir nada, y sin que se cree ninguna etiqueta ni despliegue en tu nombre.
Todo el análisis ocurre localmente en tu navegador, y nunca se etiqueta ni se publica nada en tu nombre.