La plantilla de notas de la versión

Esta plantilla de notas de la versión define las 11 secciones que un equipo de lanzamiento necesita para contarle a los usuarios qué cambió. Copia toda la estructura sin necesidad de registrarte, o descárgala en PDF.

La plantilla de notas de la versión (lista para copiar y pegar)

El bloque de abajo es la plantilla completa, lista para copiar al instante, sin registro ni paso por correo electrónico. Se pega sin cambios en Word, Google Docs, Confluence, Notion o un archivo Markdown, y el PDF conserva las mismas 11 secciones si prefieres imprimirla. Reemplaza los indicadores entre corchetes y luego elimina las secciones que esta versión no toca.

[Nombre del producto] Notas de la versión
Versión: [x.y.z]
Fecha de lanzamiento: [YYYY-MM-DD]
Plataforma / entorno: [web, iOS, Android, API, staging]

Resumen de cambios (Propósito)
[Una o dos frases: qué resuelve esta versión y a quién afecta]

Nuevas funciones
- [Qué puede hacer ahora el usuario, no el nombre interno de la función]

Mejoras y optimizaciones (Mejoras de rendimiento)
- [Qué existía ya, y qué mejora desde el punto de vista del usuario]

Correcciones de errores
- Corregido: [qué veía antes el usuario, y qué ocurre ahora]

Cambios incompatibles y pasos de migración
- [Qué deja de funcionar], por lo tanto [qué debes cambiar, y para cuándo]

Problemas conocidos y soluciones alternativas (Problemas en curso)
- [Problema sin resolver] · [plataforma afectada] · [solución alternativa] · [plazo de corrección]

Pasos de actualización o instalación (Pasos de actualización / Notas de instalación)
1. [Qué debe hacer el usuario para pasar a la nueva versión]

Obsolescencias
- [Función, integración o API] queda obsoleta el [fecha]. [A qué migrar]

Notas de seguridad
- [Cambio relevante para la seguridad, expresado sin describir la vulnerabilidad]

Dónde obtener ayuda y dejar comentarios
- Documentación: [enlace] · Soporte: [correo o canal] · Comentarios: [enlace]

Qué contiene una plantilla de notas de la versión

Una plantilla de notas de la versión tiene once secciones, cada una con una función. Escribe cada una para la persona que la lee: los desarrolladores y los clientes necesitan cosas distintas.

Cómo usar la plantilla de notas de la versión

1. Copia la plantilla en el lugar donde ya vive tu versión. Se pega sin cambios en Jira, Confluence, Notion, GitHub o Azure DevOps, así la nota queda junto al trabajo en lugar de en un documento suelto.
2. Completa primero la línea de encabezado. Nombre del producto, número de versión, fecha de lanzamiento y plataforma, para que cualquiera que llegue a la nota sepa qué build describe antes de leer una sola palabra.
3. Reúne el registro de cambios y ordénalo por lo que ve el usuario. Divide cada cambio en nuevas funciones, mejoras, correcciones de errores y cualquier cosa que se rompa, y elimina las entradas que quedan invisibles para los usuarios.
4. Escribe cada entrada como la capacidad, no como la implementación. "Se implementó el procesamiento por lotes" se convierte en "Ahora puedes exportar grandes conjuntos de datos sin que el proceso se agote por tiempo", lo que responde a la pregunta del lector sobre si esta versión lo afecta.
5. Agrega una captura de pantalla o un GIF corto dondequiera que haya cambiado la interfaz. Si una entrada necesita tres párrafos, probablemente necesite en su lugar un GIF de quince segundos.
6. Elimina las secciones que esta versión no toca y deja el resto en orden. Un parche omite las nuevas funciones y los pasos de actualización, y los usuarios no deberían tener que reaprender la estructura en cada versión.
7. Entrega el borrador a un único responsable designado, y luego publica. Sin una sola persona responsable de la aprobación final, la nota sale tarde o sale duplicada.

Plantilla de notas de la versión: un ejemplo completado

Esta es la misma plantilla, completada para un producto de despacho ficticio que lanza una versión con nuevas funciones.

• Fieldpost 4.2.0 · Lanzamiento: 12 de marzo de 2026 · Plataforma: Web e iOS
• Resumen de cambios: las exportaciones ahora terminan en cuentas grandes, los precios en Canadá son correctos, y los administradores autoalojados tienen un paso de migración.
• Nuevas funciones
• Exportaciones programadas. Ahora puedes configurar un informe para que se ejecute cada lunes y llegue a tu bandeja de entrada.
• Actualizaciones de estado masivas. Selecciona hasta 500 trabajos y cambia su estado en una sola acción.
• Mejoras y optimizaciones
• Panel de despacho más rápido. El panel carga en unos dos segundos en cuentas con 10,000 trabajos abiertos, frente a los nueve anteriores.
• Correcciones de errores
• Corregido: las exportaciones de más de 50,000 filas se agotaban por tiempo y devolvían un archivo vacío.
• Corregido: los precios se mostraban en USD para las cuentas canadienses.
• Cambios incompatibles y pasos de migración
• La versión 4.2.0 elimina el endpoint v1 /exports. Apunta las integraciones a /v2/exports, que devuelve un ID de trabajo. Las instalaciones autoalojadas ejecutan fieldpost migrate --v2-exports antes de iniciar la 4.2.0.
• Problemas conocidos y soluciones alternativas
• En iOS, las exportaciones programadas para el domingo se ejecutan el lunes. Usa la aplicación web hasta que salga la 4.2.1 el 26 de marzo.
• Pasos de actualización o instalación
• Las cuentas en la nube ya están en la versión 4.2.0. Los usuarios de iOS actualizan desde la App Store antes del 31 de marzo.
• Obsolescencias
• Fieldpost deja obsoleto el formato de informe exclusivo en CSV el 1 de septiembre de 2026. Cambia los informes guardados a XLSX.
• Notas de seguridad
• Los tokens de sesión ahora expiran a las 12 horas, y los administradores pueden cerrar la sesión de otro usuario.
• Dónde obtener ayuda y dejar comentarios
• Documentación: docs.fieldpost.example · Soporte: support@fieldpost.example · Comentarios: la pestaña Feedback de la aplicación.

Variantes de la plantilla de notas de la versión

Las cinco variantes de abajo se organizan en dos ejes: quién lee la nota, y qué tipo de versión cubre. Cada una conserva la línea de encabezado y el resumen de cambios, y luego agrega, elimina o reescribe las otras nueve secciones. Las diferencias son la parte útil, porque decidir qué eliminar en una versión pequeña es la decisión que más equipos hacen mal.

Plantilla de notas de la versión mayor

Esta variante incluye las 11 secciones completas. Cada nueva función recibe un párrafo más una captura de pantalla o un GIF, detallas los pasos de migración en lugar de enlazarlos, y escribes el resumen de cambios para que se sostenga por sí solo, ya que es la línea que los compañeros de equipo pegan en Slack y te citan después.

• Conserva: las 11 secciones.
• Amplía: nuevas funciones, cambios incompatibles y pasos de migración, pasos de actualización.
• Cuidado con: el resumen tiene que tener sentido sin ninguna otra sección adjunta.

Plantilla de notas de la versión para parche o corrección urgente

Cuatro secciones hacen la mayor parte del trabajo: línea de encabezado, resumen, correcciones de errores, y problemas conocidos si queda alguno. Empieza con la corrección, luego a quién afecta, y luego si el lector tiene que hacer algo. Una nota de corrección urgente que abre con un número de versión y entierra la corrección en el tercer párrafo anula el propósito de lanzarla rápido.

• Elimina: nuevas funciones, mejoras, obsolescencias, pasos de actualización.
• Conserva: línea de encabezado, resumen, correcciones de errores, problemas conocidos.
• Cuidado con: indicar explícitamente cuando no se requiere ninguna acción.

Plantilla de notas de la versión interna o técnica

Esta la escribes para el equipo que opera el sistema, así que el enfoque en beneficios desaparece y llega la mecánica. Nombra los servicios afectados, la configuración que cambió, y cualquier cosa con la que un compañero de equipo pueda tropezar a las 2 de la madrugada.

• Agrega: cambios de código, cambios de API y base de datos, notas de entorno y configuración.
• Elimina: el enfoque orientado a beneficios para el usuario.
• Conserva: cambios incompatibles, problemas conocidos, pasos de actualización, que pesan más en esta variante que en las demás.

Plantilla de notas de la versión para tiendas de aplicaciones móviles

Los listados de las tiendas limitan el número de caracteres, así que toda la nota se comprime a una línea de versión y una breve lista de "novedades". Escribe de tres a cinco viñetas, cada una nombrando una cosa que el usuario ya puede hacer, ordenadas por lo que más le importa.

• Conserva: línea de encabezado, una lista comprimida de nuevas funciones, una línea para correcciones destacadas.
• Elimina: problemas conocidos, obsolescencias, notas de seguridad, pasos de migración.
• Cuidado con: cualquier cosa recortada del listado de la tienda sigue perteneciendo a la nota completa que alojas tú mismo.

Plantilla de notas de la versión de API

Esta la escribes para un desarrollador que integra contra tu sistema, no para un usuario final. Cada entrada nombra el endpoint o el parámetro que afecta, y cada obsolescencia lleva una fecha de cierre que el lector puede anotar en un calendario.

• Agrega: cambios de endpoint, cambios de parámetros, un ejemplo de migración con solicitud y respuesta.
• Amplía: obsolescencias, con fechas de cierre, y cambios incompatibles.
• Elimina: capturas de pantalla y GIFs, que un lector desarrollador no necesita.

Un parche de seguridad toma la variante que corresponda a la versión, con una regla adicional: mantén la nota de seguridad objetiva y no describas la vulnerabilidad en sí.

Cuándo usar una plantilla de notas de la versión

Recurre a la plantilla en cualquier versión que un usuario pueda ver o deba atender. Los tres desencadenantes más comunes son el lanzamiento de una función, una corrección de errores o urgente, y un build interno. Los parches de seguridad, los lanzamientos de API y las actualizaciones de tienda siguen la misma estructura con distintas secciones en juego.

Las notas de la versión, un registro de cambios (changelog) y las notas de parche responden preguntas distintas. Las notas de la versión son por versión y legibles para humanos, escritas para la audiencia a la que afecta el cambio. Un changelog es el registro cronológico completo, orientado a desarrolladores y permanente. Las notas de parche son la versión corta de la nota de la versión para un lanzamiento centrado solo en correcciones. Publica notas de la versión cuando alguien fuera del equipo tenga que actuar, y mantén el changelog corriendo por debajo.

La propiedad funciona como un traspaso. Ingeniería entrega los registros de cambios, un PM o PMM los traduce en entradas orientadas al usuario, y una persona designada da la aprobación final antes de que la nota se publique.

Sáltate el documento en blanco: grábalo en su lugar

Completar una plantilla en blanco es el paso que la mayoría de los equipos posterga hasta que la versión ya salió. La otra ruta es grabar el recorrido que de todos modos ibas a mostrar y dejar que se convierta en la nota.

Hinto AI toma cualquier fuente de video, un Loom, una llamada de Zoom, un video de YouTube o un MP4 local, y graba tu pantalla desde la app web o la extensión de Chrome. Su detección de acciones con IA identifica los cambios de estado en la interfaz y los clics de botones, y extrae capturas de pantalla y pasos escritos. Esos pasos se convierten en las entradas de nuevas funciones, mejoras y correcciones de errores, y el motor de GIFs cubre los campos donde cambió la interfaz. Hinto incluye una plantilla de proyecto "Novedades" pensada para notas de la versión a partir de demostraciones de producto.

Desde ahí editas en lugar de redactar desde cero: seleccionas una sección y le pides a la IA que la reescriba, y luego alojas el resultado en una URL pública con dominio personalizado, o lo sincronizas con Notion, Confluence, GitHub o GitLab.

Preguntas frecuentes sobre la plantilla de notas de la versión

¿Qué deben contener las notas de la versión?

Once secciones: una línea de encabezado; un resumen de cambios; nuevas funciones; mejoras; correcciones de errores; cambios incompatibles y pasos de migración; problemas conocidos; pasos de actualización; obsolescencias; notas de seguridad; y dónde obtener ayuda. El resumen es la línea que leen los lectores rápidos y que citan los agentes de IA.

¿Cómo se escriben buenas notas de la versión?

Empieza por lo que el lector puede hacer ahora, y deja fuera la implementación. "Se implementó el procesamiento por lotes" se convierte en "Ahora puedes exportar grandes conjuntos de datos sin que el proceso se agote por tiempo." Resalta el nombre de la función en negrita, usa etiquetas Nuevo, Mejorado y Corregido, y limita cada entrada a dos o tres frases.

¿Quién suele escribir las notas de la versión?

Un product manager o un product marketing manager, a partir de lo que entrega ingeniería. Ingeniería aporta los registros de cambios, el PM o PMM los traduce en entradas orientadas al usuario, y una persona designada da la aprobación final antes de que salga la nota.

¿Cuál es la diferencia entre notas de parche y notas de la versión?

Las notas de parche son la forma corta para un lanzamiento centrado solo en correcciones. Omiten las nuevas funciones, las mejoras, las obsolescencias y los pasos de actualización, y empiezan con la corrección, a quién afecta, y si el lector debe actuar. Las notas de la versión llevan la estructura completa para un lanzamiento con nuevas funciones.

¿Qué son las notas de la versión en Jira?

Es el mismo documento, pegado en una superficie específica. Quienes buscan sobre Jira, Confluence, GitHub, Notion o Azure DevOps quieren la nota de la versión en sí, así que copia la plantilla de arriba en la superficie que ya usa tu equipo. Hinto publica en Notion, Confluence, GitHub y GitLab.