Generador de Changelog

Escribir changelogs a mano significa revisar el git log en el momento del lanzamiento. Este generador evita ese paso: pegas las entradas que quieres publicar directamente bajo la categoría correcta, Añadido, Cambiado, Corregido y Eliminado, añades un número de versión y una fecha, y genera una sección markdown compatible con Keep a Changelog lista para incluir en CHANGELOG.md. El mismo contenido también se puede producir como texto plano. No lee tu historial de git; tú decides qué cambios entran en el lanzamiento.

Cómo generar un changelog

  1. 1

    Introduce la versión y la fecha

    Escribe el número de versión, por ejemplo 1.2.0. Deja la fecha en blanco para usar la de hoy.

  2. 2

    Añade entradas por categoría

    Pega las notas del lanzamiento bajo Añadido, Cambiado, Corregido y Eliminado, una entrada por línea. Las categorías vacías se omiten.

  3. 3

    Elige el formato de salida

    Markdown (una cabecera `## [versión] - fecha` con secciones estilo `### Added`) o texto plano (una cabecera `v1.2.0 (fecha)` con listas con viñetas).

  4. 4

    Copia el changelog

    Pega la salida encima de la entrada anterior en CHANGELOG.md.

Las cuatro categorías

El generador produce exactamente cuatro secciones, en este orden: Added, Changed, Fixed y Removed. Los encabezados de sección de la salida se mantienen en inglés, que es la redacción estándar de Keep a Changelog.

Categoría Cuándo usar
Added Nuevas características
Changed Cambios en la funcionalidad existente
Fixed Correcciones de errores
Removed Características eliminadas

La convención Keep a Changelog también contempla las secciones Deprecated, Security y Breaking. El generador no tiene campos para ellas; puedes añadir esas secciones a mano tras pegar la salida.

Ejemplo de salida (Markdown)

## [1.4.0] - 2026-04-18

### Added
- Dark mode support for the dashboard (#312)
- CSV export on the users page (#318)

### Changed
- Upgrade React to 18.3 (#320)
- Pagination now defaults to 50 items per page (#322)

### Fixed
- Crash when editing users with a null email (#319)
- Timezone offset in scheduled reports (#321)

### Removed
- Legacy reports API (#324)

Ejemplo de salida (texto plano)

v1.4.0 (2026-04-18)
ADDED:
  • Dark mode support for the dashboard (#312)
  • CSV export on the users page (#318)
CHANGED:
  • Upgrade React to 18.3 (#320)
  • Pagination now defaults to 50 items per page (#322)
FIXED:
  • Crash when editing users with a null email (#319)
  • Timezone offset in scheduled reports (#321)
REMOVED:
  • Legacy reports API (#324)

Consejos

  • Una entrada por línea. Cada línea de un campo se convierte en una viñeta. Los campos vacíos se omiten y puedes dejar una categoría entera sin contenido.
  • Escribe las entradas como líneas del changelog, no como notas de registro. El imperativo “fix: handle null email on edit” funciona bien como viñeta.
  • Referencia números de issue/PR para que los lectores puedan profundizar: (#319) o [#319](link) en la salida.
  • Una versión por entrada: no combines dos lanzamientos en un solo bloque, aunque estén a un día de distancia.
  • Lanzado vs no lanzado: mantén una sección [Sin publicar] en la parte superior con los cambios destinados a la próxima versión. Muévelos a una sección con fecha al lanzar.

Preguntas frecuentes

Las convenciones de Keep a Changelog (keepachangelog.com): una cabecera de versión con fecha y listas con viñetas agrupadas. El generador emite las secciones Added, Changed, Fixed y Removed; las demás secciones estándar (Deprecated, Security, Breaking) siguen la misma convención si las añades a mano.

El generador produce las cuatro secciones principales: Added, Changed, Fixed y Removed. No hay campos dedicados para Deprecated, Security o Breaking, pero puedes añadir esas secciones manualmente al texto generado antes de pegarlo.

El generador es una herramienta de interfaz de un solo uso; para automatización usa un CLI como standard-version, release-please o semantic-release, que implementan los mismos patrones en tu pipeline de construcción.

No. No lee tu repositorio ni tus mensajes de commit; tú pegas las entradas. El texto que escribes se envía al servidor para construir la salida y no se almacena ni se comparte.

Herramientas relacionadas