Las notas de versión cuentan a los clientes qué cambió en una versión del producto, en lenguaje simple y agrupado por tipo: novedades, mejoras, correcciones y lo que dejará de existir. El changelog interno registra todo, incluidos los cambios técnicos y las referencias de tickets, para dar trazabilidad. El formato estándar de changelog organiza las versiones en un único archivo, de la más reciente a la más antigua.
Cómo usar
- Indica el producto, la versión (de preferencia MAJOR.MINOR.PATCH) y la fecha.
- Lista los cambios con tipo, descripción, público (clientes o interno) y referencia del ticket.
- Escribe el destacado de la versión y, si la hay, la acción que deben tomar los clientes.
- Lee los avisos: términos técnicos en notas para clientes e ítems obsoletos sin reemplazo.
- Exporta en Markdown para el blog de novedades, el centro de ayuda o el archivo CHANGELOG.
Qué pide cada campo
| Campo | Qué completar |
|---|---|
| Producto | Ej.: Agenda Fácil |
| Versión | De preferencia en formato MAJOR.MINOR.PATCH. |
| Fecha | Opcional. El formato AAAA-MM-DD funciona en cualquier idioma. |
| Tipo | Nuevo, mejora, corrección u obsoleto. |
| Descripción | Ej.: recordatorio por mensaje 2 horas antes de la cita |
| Público | Los clientes lo ven en las notas; lo interno queda en el changelog. |
| Referencia | Código del ticket (opcional, no lo ven los clientes). |
| Destacado de la versión | La frase que abre las notas (opcional). |
| Acción necesaria | Lo que el cliente debe hacer, si hace falta (opcional). |
Ejemplo
La versión 2.4.0 de una app ficticia de reservas tiene 6 cambios, 5 de ellos para clientes. Las notas abren con el destacado de las reservas recurrentes y resumen: 2 novedades, 1 mejora, 1 corrección y 1 ítem que deja de existir. El ajuste técnico de caché queda solo en el changelog interno, con la referencia del ticket. La exportación en el formato antiguo aparece en "dejará de existir", con el reemplazo y el plazo, y una acción necesaria avisa que hay que pasar a CSV antes del 31/12.
Cuándo usar
- Con cada versión publicada, para avisar a los clientes sin copiar la lista de tickets.
- Para mantener ordenado un archivo de changelog sin escribir dos veces lo mismo.
- Cuando una funcionalidad va a dejar de existir y los clientes necesitan saber qué hacer.
- Para revisar que las notas para clientes no tengan jerga técnica antes de publicar.
Preguntas frecuentes
¿Cuál es la diferencia entre notas de versión y changelog?
Las notas de versión son para clientes: pocas líneas, lenguaje simple, foco en lo que cambia para quien usa el producto. El changelog es el registro completo de cambios, incluidos los técnicos, pensado para el equipo y para quien integra con el producto.
¿Qué es el formato estándar de changelog?
Es una convención abierta para archivos de changelog: cada versión es una sección "[versión] - fecha", con los cambios agrupados en añadido, cambiado, corregido y obsoleto, de la más reciente a la más antigua.
¿Qué es el versionado MAJOR.MINOR.PATCH?
Es una forma de numerar versiones: el primer número sube cuando hay un cambio que rompe la compatibilidad, el segundo con una novedad compatible y el tercero solo con correcciones. La herramienta avisa cuando la versión no sigue este formato.
¿Cómo escribir notas en lenguaje de cliente?
Di qué cambia para quien usa el producto, no lo que hizo el equipo por dentro. Cambia "ajuste en la API" por "la agenda abre más rápido", quita los códigos de ticket y usa frases cortas.
¿Cómo comunicar algo que dejará de existir?
Di qué deja de funcionar, hasta cuándo, qué usar en su lugar y qué debe hacer la persona. La herramienta avisa cuando un ítem obsoleto no indica el reemplazo ni el plazo.
¿Con qué frecuencia publicar notas de versión?
Con cada versión que cambie algo visible para los clientes. Los equipos con entrega continua suelen agrupar los cambios en notas semanales o quincenales.