Ejemplos de changelog

1. Un release de SaaS normal

El caso habitual: un puñado de cambios visibles para el usuario, sin migración, sin drama. Es corto porque el release era pequeño, y resistir la tentación de rellenarlo es la mayor parte del oficio.

## 20 de agosto de 2026

### Nuevo
- Vistas guardadas en la bandeja. Fija un filtro una vez y reutilízalo
  desde el lateral.

### Mejorado
- El job de exportación ahora informa del progreso en vez de parecer
  colgado en cuentas grandes.

### Corregido
- Los miembros invitados ya no ven un dashboard vacío antes de su
  primer inicio de sesión.

2. Un release de API con una deprecación

Quien lee un changelog de API busca una cosa: si su integración está a punto de romperse y de cuánto tiempo dispone. Ponlo arriba y dale una fecha.

## Acme API 4.2 - 20 de agosto de 2026

### Cambios importantes
- `?page=` se elimina en todos los endpoints de listado. Usa el valor
  `nextCursor` de la respuesta anterior.
  `?page=` devolverá 400 a partir del 1 de octubre de 2026.
  Pasos de migración: acme.example/docs/pagination

### Nuevo
- Los webhooks pueden limitarse a un solo proyecto.

### Mejorado
- Los endpoints de listado responden unas cuatro veces más rápido en
  cuentas con más de 10.000 registros.

3. Un release móvil

Las tiendas de apps muestran un campo de novedades recortado, y la revisión puede retener un build durante días. Ambos hechos moldean la entrada.

## iOS 3.4.0 - 20 de agosto de 2026

Modo sin conexión. Abre, lee y redacta sin conexión;
todo se sincroniza al volver a estar en línea.

### También en este release
- Arranque más rápido en dispositivos antiguos.
- Corregido un cierre inesperado al abrir un enlace compartido desde Mail.

4. Una corrección de seguridad

La única entrada donde decir menos es lo correcto. Los usuarios necesitan saber que deben actualizar; nadie más necesita una descripción tan precisa como para atacar la versión que aún no han actualizado.

## 20 de agosto de 2026

### Seguridad
- Reforzada la validación de los tokens de sesión. Las cuentas en
  instalaciones autoalojadas deberían actualizar a 4.2.1 o posterior.
  Notificado de forma responsable; sin indicios de explotación.
  Detalles: acme.example/security/2026-08

5. Cómo es una entrada mala

Cada línea aquí tiene una forma real, y cada línea es un error:

## v2.3.7

- PR #482 de feature/inbox-refactor fusionada
- Bump de lodash 4.17.20 -> 4.17.21
- Corregida condición de carrera en MembershipCache.resolve()
- Varias correcciones y mejoras
- Refactorizado el modelo SavedView (¡gracias, Dave!)

Qué tienen en común las buenas

• Describen un resultado, no una implementación. Alguien que nunca ha visto el código puede saber si la entrada le afecta.
• Omiten cosas. Los cambios de dependencias, los refactors, los cambios de CI y los renombrados internos están ausentes, y esa ausencia es lo que mantiene legible el resto.
• Ponen primero lo costoso. Si algo se rompe, es el primer encabezado, con fecha.
• Están fechadas de una forma útil: un número de versión donde los usuarios ven versiones, una fecha donde no pueden.
• Son aburridas a propósito. Sin signos de exclamación, sin adjetivos de marketing, sin «nos alegra anunciar». Quien lee un changelog busca información y le molesta cualquier cosa que se interponga.

Preguntas frecuentes

¿Qué formato debería usar un changelog?

keepachangelog.com es lo más parecido a un estándar, y sus nombres de sección (Added, Changed, Deprecated, Removed, Fixed, Security) son ampliamente reconocidos. Importa mucho menos que la redacción dentro de las secciones. Un formato consistente con entradas vagas es peor que uno libre con entradas concretas.

¿Con qué frecuencia deberíamos publicar?

Con el ritmo que encaje con tus releases, y de forma constante. Publicar por release es la regla más simple. Agrupar un mes de releases en una sola entrada hace que cada cambio sea más difícil de encontrar después, que es cuando la mayoría de la gente realmente lee un changelog.

¿Debería el changelog vivir en nuestro sitio o en una página de terceros?

En tu sitio si puedes, porque ahí se acumulan el tráfico y el valor de búsqueda, y porque un changelog en un dominio ajeno está a un enlace de tu producto en vez de formar parte de él. Ese es el argumento a favor de servirlo como un feed que renderizas tú, en lugar de una página alojada que enlazas.

¿La gente lee de verdad los changelogs?

Una pequeña parte los lee con regularidad y una parte mucho mayor los busca en el momento en que algo cambia bajo sus pies. Ese segundo grupo es la razón para escribir el síntoma en lugar de la causa: buscan lo que les pasó, con sus propias palabras.

Para seguir leyendo: Changelog vs. notas de versión: ¿cuál es la diferencia? y Keep a Changelog, implementado de verdad.