Saltar al contenido

Herramientas de changelog comparadas

Última actualización: 20 de agosto de 2026.

Bajo la etiqueta herramienta de changelog se venden tres cosas distintas, y elegir de la categoría equivocada es el motivo habitual de que los equipos acaben descontentos. Esta página las separa por lo que realmente hacen, dice a quién le conviene cada una y es explícita sobre dónde no encaja nuestro propio producto.

Nosotros hacemos una de las herramientas de esta página. Hemos intentado describir las demás por para qué están construidas, no por dónde fallan, y la sección sobre nuestro propio producto dice con claridad quién no debería usarlo.

Las tres categorías

Widget y página alojados

Escribes las entradas en su editor, ellos alojan la página y te dan un widget in-app. Lo más rápido de lanzar, y las entradas viven en su infraestructura, no en la tuya. Beamer y AnnounceKit son los ejemplos más claros.

Suite de feedback con changelog incluido

El changelog es un módulo junto a la votación de funciones, una roadmap pública y una bandeja de feedback. Vale la pena si quieres todo el ciclo de un solo proveedor, sobredimensionado si solo quieres publicar release notes. Canny, Frill y Featurebase están aquí.

Generado desde tu repositorio

El changelog se produce a partir de commits, pull requests o issues en vez de escribirse a mano. Va desde un archivo construido en la CI hasta una entrada redactada, revisada y publicada. git-cliff y github-changelog-generator están en el extremo del archivo; LaunchNotes, Released y nuestro propio producto en el extremo publicado.

De un vistazo

HerramientaTipoIdeal para
BeamerWidget alojadoPoner en marcha esta misma tarde un panel de novedades dentro de la app, sin tiempo de ingeniería.
AnnounceKitWidget alojadoLo mismo, con más atención a segmentar quién ve cada anuncio.
CannySuite de feedbackEquipos que quieren votación de funciones y una roadmap pública, con el changelog como último paso de ese ciclo.
FrillSuite de feedbackEquipos más pequeños que quieren lo mismo que Canny, pero más ligero.
LaunchNotesDesde el repositorioOrganizaciones grandes que coordinan anuncios entre equipos, a menudo con Jira como eje.
ReleasedDesde el repositorioEquipos que viven en Jira y quieren el changelog generado a partir de los issues sin salir de él.
git-cliffGenerador de archivosProyectos de código abierto que quieren un CHANGELOG.md generado a partir de conventional commits en la CI, sin nada alojado.
ChangeloopDesde el repositorioEquipos que quieren la entrada redactada a partir de pull requests fusionadas y renderizada después por su propio front end desde un feed JSON.

Cómo elegir

  1. Empieza por dónde tiene que aparecer el changelog. Si tiene que parecer parte de tu producto, una página alojada que enlazas te decepcionará por muy bueno que sea su editor; entonces quieres o un widget reestilizable o un feed que renderices tú. Si una página enlazada es suficiente, las herramientas alojadas son mucho menos trabajo.
  2. Pregunta luego quién escribe las entradas. Si la respuesta es «la persona que lo fusionó», elige algo que lea tu repositorio, porque cualquier otra cosa añade un paso manual justo cuando todos están ocupados. Si la respuesta es alguien de marketing de producto trabajando con un plan de releases, un editor encaja mejor y la automatización desde el repositorio solo estorbará.
  3. Pregunta luego si necesitas el resto del ciclo. La votación de funciones y una roadmap pública son realmente útiles y realmente un compromiso mayor. Comprar una suite por su módulo de changelog es como los equipos acaban pagando por cuatro cosas para usar una.
  4. Comprueba por último qué pasa con tus entradas si te vas. Una herramienta que las exporta como datos estructurados es muy distinta de una en la que viven en una página alojada que tendrías que scrapear.

Dónde encaja nuestra propia herramienta, y dónde no

Changeloop lee cada pull request fusionada, redacta una entrada de cara al usuario, filtra los cambios de dependencias y los refactors, y retiene el borrador para revisión. Lo que se publica va a un feed JSON público con un feed de roadmap al lado, más un widget de dos líneas y una página alojada como alternativas. El feed es la clave: lo previsto es que renderices tu changelog con tus propios componentes en tu propio producto.

No la elijas si:

  • Tus releases no salen de tus repositorios. Redacta a partir de fusiones o, en modo push, de pushes, así que un equipo que entrega fuera de un flujo de trabajo con Git no tiene nada que revisar.
  • Quieres votación de funciones y una roadmap que tus usuarios voten. Hay un feed de roadmap, pero se alimenta de issues etiquetados, no de votos. Para eso, una suite de feedback es la categoría correcta.
  • Quieres un editor cuidado y una página alojada como producto principal. La página alojada existe como alternativa, y las herramientas construidas en torno a la suya lo harán mejor.
  • Llevas en solitario un proyecto de código abierto y solo quieres un CHANGELOG.md en el repositorio. Usa git-cliff, que es gratis y está hecho exactamente para eso.

Preguntas frecuentes

¿Nos hace falta una herramienta?

Durante un tiempo, no. Un archivo Markdown, o una página en tu propio sitio, es un changelog perfectamente válido y no cuesta nada. Una herramienta empieza a valer la pena cuando escribir las entradas es el paso que se salta, o cuando quieres las mismas entradas en tres sitios sin mantener tres copias.

¿Podemos dejar más adelante una de estas herramientas?

Depende por completo de si las entradas vuelven a salir como datos estructurados. Pregúntalo antes de empezar, no después: es la única pregunta de esta lista cuya respuesta equivocada sale cara, porque un changelog es un archivo que crece, y volver a teclear dos años de él no es un proyecto que nadie apruebe.

¿Y escribirlas con un asistente de IA?

La mayoría de estas herramientas ya redactan con algún modelo por detrás. Importa menos eso que lo que se le da al modelo. Una herramienta que solo ve un asunto de commit solo puede reescribir ese asunto; una que ve el título y la descripción de la pull request tiene suficiente para describir el cambio en términos de lo que hace por el usuario. Pregunta cuál es la entrada, no si hay IA.

Para seguir leyendo: Automatización de changelog, y sus límites, sobre cuál de los cuatro pasos debería ser automático.

La que da prioridad al feed

Redactada a partir de tus pull requests fusionadas, retenida para revisión, publicada en un feed JSON que renderizas tú. Gratis para un repositorio, sin tarjeta.

Empezar gratis

o ir a la documentación para desarrolladores