Changelog: qué es, cómo escribirlo y cómo avisarle a quien pidió cada cambio

Después de ocho meses sale la exportación a Excel. La pidieron cuarenta clientes, repartidos entre correos, chats de soporte y una reunión de ventas. El equipo lo celebra en Slack, alguien publica un post y el tema se da por cerrado. Tres semanas después, uno de esos cuarenta cancela y en la encuesta de salida escribe “les faltaba exportar a Excel”.

Ese cliente se fue sin saber que lo que pidió ya estaba. Un changelog bien escrito resuelve la mitad del problema. La otra mitad es avisarle a cada persona que pidió el cambio, en el momento en que lo puede usar.

Qué es un changelog

Un changelog es el registro público y fechado de los cambios de un producto, con lo más reciente primero. Cada entrada cuenta qué cambió, a quién le sirve y desde cuándo está disponible.

En proyectos de código abierto, la referencia es Keep a Changelog, que agrupa los cambios en agregados, cambiados, obsoletos, eliminados, corregidos y de seguridad. Ese formato está pensado para quien lee un repositorio. A los usuarios de un SaaS les alcanzan tres grupos: Nuevo, Mejorado y Corregido.

Changelog, notas de versión y anuncio se usan como sinónimos, aunque cada uno le habla a alguien distinto:

Cómo escribir un changelog que alguien lea

• El título dice qué puede hacer ahora el usuario. “Exporta tus reportes a Excel” dice más que “Mejoras en reportes”.
• La primera frase explica para qué sirve; la segunda, dónde está.
• Los arreglos se cuentan por el síntoma que veía el usuario: “las facturas ya no salen con la fecha del día anterior”. El número del ticket interno no le dice nada.
• Una imagen o un GIF cuando el cambio es visual.
• Un enlace al pedido original, para que quien lo votó vea de dónde salió.
• Afuera queda lo que el usuario no ve: cambios internos de código, dependencias y migraciones.

La misma versión, escrita dos veces:

Sobre la frecuencia: una entrada por versión si publicas versiones, o una por semana que junte lo que el usuario nota si despliegas varias veces al día. La regularidad pesa más que el volumen. Una entrada semanal durante un año muestra un producto vivo; veinte en una semana y después silencio, lo contrario.

Los tres avisos que cierran el ciclo

Una entrada publicada que nadie abre no cierra nada. Cada grupo de usuarios necesita su propio aviso:

1. A quien lo pidió o lo votó

Un correo personal que diga “lo que pediste ya está disponible”, con el enlace. Es el aviso que más vale y el que menos se manda, porque exige saber quién pidió qué. Si los pedidos viven en un portal con votos, esa lista ya existe; si llegaron por soporte, la respuesta en el mismo ticket hace el mismo trabajo.

2. A todos tus usuarios

La entrada en la página pública de novedades y dentro de tu app, con un contador de lo no leído en un lugar que ya miran. Si además mandas un correo general, que sea un resumen y que tenga baja en un clic.

3. A quien reportó un error

Un mensaje corto: “arreglamos el error que reportaste”. Esa persona se tomó el tiempo de avisar que algo fallaba, y este correo le confirma que sirvió. Si prefieres partir de un texto armado, hay plantillas de respuestas de soporte para adaptar.

Cuándo avisar: con el cambio en producción

Un error frecuente es avisar cuando el cambio se aprueba o se fusiona en el código, y no cuando el usuario lo puede usar. Entre una cosa y otra pueden pasar días, y un correo que dice “ya está” cuando todavía no está produce un ticket de soporte en lugar de una buena noticia.

El aviso sale cuando la versión con el cambio está en producción. Si activas la función de a poco, cuando le llega a la persona que la pidió. Y si el cambio se revierte, corrige la entrada en vez de borrarla, porque el historial también es parte del registro.

Cómo lo hace Melonhelp Feedback

En Melonhelp Feedback el changelog está conectado a los pedidos del portal, así que la lista de a quién avisar sale de los votos.

• Cada entrada se vincula a los pedidos que resuelve, y la página pública de novedades muestra en qué pedidos se pidió cada cambio.
• La escribes en Markdown, la guardas como borrador, la programas para una fecha o la publicas en el momento. Al publicar eliges si avisar por correo.
• Feedback prepara un borrador a partir de los pedidos que vinculaste, y tú lo revisas antes de publicar.
• Con aviso, quienes publicaron, votaron, comentaron o siguieron un pedido incluido reciben un correo que dice que la novedad incluye algo que pidieron o votaron. El resto de tus usuarios con correo verificado recibe el aviso general, salvo que se haya dado de baja.
• Dentro de tu app, el botón de feedback tiene una pestaña Novedades con un contador de lo que cada usuario no ha leído.
• Al mover un pedido a Lanzado, sus seguidores reciben “Lo que pediste ya está disponible”, aunque todavía no hayas escrito la entrada.
• Los correos salen solo a direcciones verificadas, con el token que firma tu app o con un enlace mágico, y cada uno trae su enlace de baja.

Con un agente de código

Si conectas tu agente por MCP (Claude Code, Codex, Cursor u otro cliente compatible), el cierre también puede salir de ahí:

• resolve_issue marca el pedido como resuelto. En ideas y en errores que reportan tus usuarios, los seguidores reciben el aviso en el momento, así que úsalo con el cambio ya en producción.
• En los errores que captura tu código, resolve_issue con la versión deja el aviso en espera, y register_release lo envía cuando registras esa versión ya desplegada. Si el error vuelve en esa versión o en una posterior, se reabre como regresión.
• draft_changelog crea el borrador de la entrada con los pedidos resueltos. Nunca se publica solo.
• reply_to_user prepara una respuesta pública para quien lo pidió, que espera tu aprobación en la bandeja.

El registro de versiones depende del plan; los detalles están en la página de Melonhelp Feedback y en la documentación del MCP. Cómo ordenar los pedidos antes de llegar acá (estados, votos y duplicados) está en roadmap público con votación.

Preguntas frecuentes