Notas de versión y registro de cambios

Las notas de versión son el registro fechado y de primera parte de un cambio de producto: qué se lanzó, a quién afecta, qué se comporta de manera diferente y qué debe hacer el usuario a continuación. Un registro de cambios es la colección cronológica de esas entradas. El formato es una herramienta de retención antes que un activo de tráfico; los clientes lo usan para planificar su trabajo y evitar sorpresas.

La regla fundamental es consecuencia antes que celebración. Un lanzamiento puede ser emocionante para el equipo, pero el lector primero necesita saber si su flujo de trabajo, integración, datos, permisos, precio o compatibilidad cambiaron. Indica esa consecuencia en lenguaje sencillo, luego explica la capacidad. Dentro del sistema de tipos de publicaciones SEO , las notas de versión son contenido de soporte en la etapa de retención; su valor proviene de registros permanentes que nunca se reescriben silenciosamente.

Preguntas que responde

Una entrada completa de notas de versión responde las preguntas que un usuario actual se hace después de ver un cambio de producto o encontrar un comportamiento desconocido:

• ¿Qué cambió, y en qué fecha de lanzamiento o versión cambió?
• ¿El cambio está disponible ahora, se está implementando gradualmente, está en beta, o está limitado por plan, región, plataforma o tipo de cuenta?
• ¿Quién está afectado, incluyendo administradores, usuarios finales, desarrolladores, socios o una integración definida?
• ¿Cuál era el comportamiento anterior y qué es diferente ahora?
• ¿Necesita el usuario migrar, actualizar configuraciones, reautorizar el acceso, recapacitar a colegas o no tomar ninguna acción?
• ¿El cambio es drástico, obsoleto, reversible, sensible a la seguridad o probable que altere datos almacenados?
• ¿Dónde están las instrucciones actualizadas, la referencia técnica, las limitaciones conocidas y la ruta de soporte?
• ¿Cómo puede un lector verificar que el nuevo comportamiento está activo en su cuenta?

No hagas que los lectores infieran el impacto a partir de etiquetas como «mejorado», «actualizado» o «optimizado». «Las exportaciones están mejoradas» es promocional pero no verificable. «Las exportaciones CSV ahora incluyen los filtros de país y modelo aplicados en dos nuevas columnas; las columnas existentes y el orden permanecen sin cambios» define el cambio observable y su límite de compatibilidad.

Cuándo usar este tipo de publicación

Usa notas de versión cuando un evento se ha lanzado o tiene un estado de disponibilidad firme y crea una diferencia visible para el usuario que vale la pena preservar en el historial del producto. La intención de búsqueda suele ser de navegación o informativa: los lectores buscan un producto más «notas de versión», un número de versión, una funcionalidad modificada, una obsolescencia o una etiqueta de interfaz desconocida. No uses el formato como una lista de promesas pendientes, un feed de anuncios generales o un sustituto de la documentación de tareas.

Un cambio no necesita una nueva interfaz para calificar. Comportamiento de API, retención, cálculos, autenticación, formatos, límites, valores predeterminados, facturación y accesibilidad pueden requerir una entrada. Una refactorización interna sin consecuencias observables no lo requiere.

Mejor para estos tipos de negocio

La clasificación refleja la necesidad de mantener un contrato público fechado con los usuarios existentes.

1. SaaS . El mejor ajuste porque las interfaces, API, permisos, integraciones y límites de planes de entrega continua pueden cambiar entre visitas de clientes. Las entradas deben incluir el estado de implementación, los planes afectados, el impacto en el administrador y enlaces a la documentación.
2. Marketplaces . Alto valor porque un solo lanzamiento puede afectar de manera diferente a compradores, vendedores, moderadores, destinatarios de pagos o socios. Segmenta el impacto y evita presentar un cambio específico de un participante como universal.
3. Comercio electrónico . Útil para cambios en cuenta, proceso de pago, suscripciones, devoluciones, fidelización, entrega y herramientas comerciales. Separa el impacto en el cliente del escaparate del impacto en el operador o la integración, especialmente en lo relacionado con pagos y estados de pedidos.
4. Fabricantes y proveedores industriales . Importante para firmware, software de control, equipos conectados, portales técnicos y revisiones de especificaciones. La versión, compatibilidad con modelos, límites de seguridad y disponibilidad de reversión deben ser explícitos.
5. Finanzas, fintech y seguros . Valioso pero con revisión intensiva, porque los cambios en cálculos, elegibilidad, divulgación, autenticación y manejo de datos pueden tener consecuencias regulatorias. Registra la jurisdicción, aprobación, fecha de vigencia y comportamiento reemplazado.
6. Servicios B2B . Útil de forma selectiva cuando el servicio incluye una plataforma mantenida, metodología, conjunto de datos, portal de clientes o entregable estándar. Las noticias empresariales ordinarias pertenecen a otro lugar a menos que cambien el contrato del cliente o el flujo de trabajo.

Intención de búsqueda

La demanda de notas de versión suele ser de bajo volumen y alta especificidad. Las consultas incluyen un nombre de producto con «registro de cambios», «última versión», «qué cambió», «nuevo panel», una versión de API, un error introducido después de una actualización o una fecha de obsolescencia. El buscador no está pidiendo una propuesta amplia del producto. Quiere una marca de tiempo autorizada y suficiente detalle para tomar una decisión.

La forma útil del resultado comienza con producto + versión o fecha + cambio + impacto. Coloca estos datos en el título, el resumen inicial, los encabezados y los metadatos sin obligar a que cada entrada menor tenga su propia URL indexable. Las anclas estables permiten que los equipos de soporte y las respuestas de IA citen una entrada; las páginas dedicadas están justificadas cuando un lanzamiento tiene un trabajo de migración sustancial, demanda distintiva o varios cambios relacionados.

Las notas de versión son una señal de actualidad subestimada porque exponen cambios reales al ritmo que ocurren. Esto no justifica cambiar fechas para parecer activo. La fecha de entrada, la documentación actual, el comportamiento del producto y la guía de migración deben coincidir.

Estructura de la página

Las bandas de palabras establecen énfasis, no cuotas. Mantén el mismo orden de campos para que los lectores puedan escanear tanto pequeñas correcciones como lanzamientos drásticos.

Agrupa los cambios con etiquetas estables como Añadido, Cambiado, Corregido, Obsoleto, Eliminado, Seguridad, pero nunca dejes que una etiqueta reemplace la explicación. «Corregido: exportaciones» no es un registro útil. Cada elemento debe nombrar el síntoma o limitación anterior, el nuevo estado observable, el alcance afectado y cualquier acción requerida.

Elementos requeridos

La posición es parte del control de riesgos: una advertencia de migración mostrada después de la celebración de la funcionalidad llega demasiado tarde.

Frontmatter y datos estructurados

Sigue la especificación de frontmatter . Esta página del playbook usa entity = "post-type-release-notes". Un registro de cambios producido debe usar un valor estable de producto-y-flujo como entity = "atlas-cloud-release-notes"; un lanzamiento individual puede usar entity = "atlas-cloud-2026-08". No uses un eslogan de campaña o un título de lanzamiento mutable como identificador.

Usa schemaType = "Article" para una página individual de notas de versión. Si el sitio expone un índice como entidad distinta, CollectionPage puede describir ese índice mientras cada entrada importante sigue siendo un elemento fechado visible. Añade FAQPage solo cuando el FAQ es visible y está respaldado por la implementación. No uses HowTo simplemente porque las instrucciones de migración contengan pasos, y no marques un producto como recién lanzado cuando la página solo corrigió redacción.

Almacena la fecha de lanzamiento por separado de las fechas de publicación y modificación. Los campos recomendados incluyen product, stream, version, status, releasedAt, platforms, plans, regions, affected roles, breakingChange, actionRequired, deprecationDate, owner, canonical URL y documentation targets. Para una implementación por fases, mantén una fecha de lanzamiento e indica la ventana en el texto visible.

Ejemplo completo

El ejemplo ficticio a continuación demuestra un lanzamiento importante. Mantiene la consecuencia de la migración antes del resumen de la funcionalidad y usa una URL de versión estable.

+++
title = "Notas de versión de Atlas Cloud 4.8 — 27 de agosto de 2026"
seoTitle = "Notas de versión de Atlas Cloud 4.8: Migración de la API de exportación"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "notas de versión de Atlas", "API de exportación v2", "registro de cambios de Atlas", "migración de exportación", "actualizaciones de producto de Atlas" ]
description = "Atlas Cloud 4.8 añade vistas de exportación guardadas y API v2, explica la fecha límite de obsolescencia de v1 y ofrece a los administradores una ruta de migración y validación probada."
type = "academy"
date = "2026-08-27 10:00:00"
schemaType = "Article"
product = "Atlas Cloud"
version = "4.8"
releaseStatus = "rolling-out"
releasedAt = "2026-08-27"
platforms = [ "web", "API" ]
affectedRoles = [ "administrador del espacio de trabajo", "responsable de integración" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Notas de versión de Atlas Cloud 4.8

Atlas Cloud 4.8 comenzó a implementarse el 27 de agosto de 2026. Añade vistas de exportación guardadas y Export API v2. Los miembros del espacio de trabajo pueden usar las vistas guardadas sin cambiar las exportaciones existentes. Los responsables de integraciones que usan API v1 deben migrar antes del 15 de octubre de 2026; después de esa fecha, las solicitudes de exportación v1 devolverán una respuesta de versión no soportada.

## Acción requerida: migrar Export API v1

**Quién está afectado:** integraciones que envían solicitudes a `/api/v1/exports`. Las exportaciones del panel y los clientes de API v2 no están afectados.

**Qué cambia:** v2 requiere un valor `format` explícito y devuelve el identificador del trabajo de exportación en `data.id`. Las columnas del archivo no cambian a menos que una vista guardada seleccione un conjunto de campos diferente.

**Fecha límite:** completa la migración y validación antes del 15 de octubre de 2026. Las solicitudes v1 existentes seguirán funcionando hasta entonces.

1. Crea una solicitud de prueba contra el endpoint v2 con los mismos filtros que una solicitud v1 actual.
2. Añade el valor `format` requerido y lee el identificador del trabajo desde `data.id`.
3. Compara el número de filas, el conjunto de campos, la zona horaria y un registro conocido entre los archivos antiguo y nuevo.
4. Actualiza la producción solo después de que la comparación sea exitosa. Mantén la configuración anterior disponible hasta que la primera exportación programada de producción tenga éxito.

Si la prueba no coincide, deja la integración de producción en v1 y envía al soporte el ID de solicitud anonimizado, la marca de tiempo, la zona horaria y la discrepancia de campos. No incluyas un token de acceso.

## Añadido: vistas de exportación guardadas

Los administradores del espacio de trabajo pueden guardar un conjunto nombrado de campos, filtros, ordenación y formato de archivo. Los miembros con permiso de exportación pueden reutilizar la vista; guardar una vista no otorga acceso a registros que ya no pudieran ver.

Para verificar la disponibilidad, abre **Exportaciones → Vistas** y busca **Guardar vista actual**. El control puede tardar hasta tres días en aparecer durante la implementación. Está incluido en los planes Standard y Enterprise en todas las regiones.

## Corregido: etiquetas de filtro de país en archivos CSV

Las exportaciones CSV ahora usan el nombre visible del país en la columna de resumen del filtro en lugar del valor interno de dos letras. Esto solo cambia la etiqueta de resumen; los registros filtrados y las columnas de datos existentes no cambian.

## Limitaciones conocidas

Las vistas guardadas aún no se pueden transferir entre espacios de trabajo. Un campo eliminado se elimina de la vista la próxima vez que se ejecute, y el historial de exportaciones registra esa omisión.

## Recursos actualizados

- Guía de migración de Export API v2
- Referencia de Export API
- Documentación de permisos de exportación
- Solución de problemas de exportación

El ejemplo nombra un límite de compatibilidad probado, distingue la implementación de la fecha de lanzamiento y ofrece a los lectores una forma de verificar el acceso.

Galería de diseño

Mantén los mismos datos del lanzamiento en cada variante de diseño para que la revisión de diseño pruebe la jerarquía, no decisiones editoriales diferentes.

Lista de verificación de calidad

Una nota de versión está lista solo cuando cada afirmación aplicable es verdadera:

• El título y la apertura identifican el producto, la fecha o versión, el cambio principal y la audiencia afectada.
• La disponibilidad es precisa: lanzado, implementándose con una ventana, beta, opt-in, limitado por plan, limitado por región, pospuesto o retirado.
• Cada entrada explica el comportamiento observable antes y después en lugar de basarse en «mejorado», «optimizado» o «corregido».
• Las etiquetas Añadido, Cambiado, Corregido, Obsoleto, Eliminado y Seguridad se aplican de manera consistente.
• Los cambios drásticos aparecen antes de los beneficios promocionales e indican el alcance afectado, la fecha límite, el modo de fallo, el reemplazo, la migración, la validación, la ruta de reversión o soporte.
• Las fechas distinguen lanzamiento, publicación, modificación sustancial, obsolescencia y eliminación.
• Los identificadores de versión, nombres de endpoints, etiquetas de menú, planes, regiones y alcance de plataforma se han verificado contra el estado lanzado.
• El lector puede saber si se requiere acción y cómo confirmar su finalización.
• La documentación actual refleja el nuevo comportamiento y enlaza de vuelta al lanzamiento relevante donde el historial importa.
• Las capturas de pantalla tienen una fecha o versión de captura y un equivalente textual para los controles o estados que muestran.
• El archivo proporciona URLs o anclas estables, navegación de lo más nuevo a lo más antiguo y una forma de acceder a entradas antiguas.
• Las respuestas del FAQ en frontmatter y las respuestas del FAQ visibles coinciden exactamente, y los análisis distinguen la navegación de la migración o la acción del producto.

Errores comunes

Escribir texto de campaña en lugar de un registro. «Estamos encantados de transformar tu flujo de trabajo» retrasa el hecho. Comienza con el comportamiento lanzado, la audiencia, la disponibilidad y la acción; coloca la narrativa en un anuncio de lanzamiento separado.

Ocultar cambios drásticos. Una fecha límite de migración debajo de capturas de pantalla y beneficios crea fallos evitables. Coloca la advertencia primero y hazla comprensible de forma independiente.

Llamar lanzamiento a una implementación en todas partes. Si solo algunas cuentas tienen acceso, di implementación y proporciona la ventana esperada. Los usuarios pierden confianza cuando las instrucciones describen un control que aún no pueden ver.

Usar «corrección de errores y mejoras». Esto oculta el comportamiento afectado e impide que los usuarios reconozcan que su problema se resolvió. Nombra el síntoma, el alcance y el nuevo estado a menos que la divulgación de seguridad requiera moderación.

Mover fechas por actualidad. Una corrección tipográfica no convierte un lanzamiento antiguo en nuevo. Preserva releasedAt, registra una corrección sustancial por separado y usa lastmod solo cuando el registro visible cambió de manera significativa.

Duplicar instrucciones actuales. Un procedimiento de configuración extenso se desviará en dos lugares. Resume el paso modificado en la nota de versión y deja que la documentación mantenida posea el flujo de trabajo completo actual.

Enlazado interno

Un buen enlazado interno convierte el registro de cambios en la capa histórica del conocimiento del producto. Enlaza desde la documentación actual cuando una transición explique un comportamiento cambiado. Enlaza desde el lanzamiento a la documentación exacta, migración, solución de problemas, política o guía de compatibilidad donde el usuario lo necesite.

Usa un registro canónico para cada cambio material. Una publicación de lanzamiento, página de funcionalidad o respuesta de soporte pueden citarlo; ninguna debe copiarlo. La navegación del archivo debe conectar lanzamientos adyacentes y el índice. Para obsolescencias, enlaza la entrada antigua a su reemplazo y la guía de migración de vuelta al aviso.

Cómo medir los resultados

Mide si los usuarios descubren el registro correcto, comprenden el impacto, completan la acción requerida y necesitan menos aclaraciones. Las visitas a la página en bruto no son el objetivo: una corrección pequeña puede cumplir su propósito con poco tráfico.

Usa el seguimiento de prompts para preguntas de producto más versión, nombres de funcionalidades modificadas, fechas de obsolescencia y redacción de «última actualización». Usa la inteligencia de fuentes y citas para inspeccionar si las respuestas de IA citan la entrada canónica y preservan la disponibilidad, el alcance afectado, la fecha límite y la acción requerida. El AmICited Cockpit puede situar la visibilidad relacionada con lanzamientos y las URLs citadas junto a la actividad orgánica de aterrizaje y eventos seleccionados del producto.

Antes de publicar, registra la audiencia afectada, la ventana de implementación, el volumen de soporte, la línea base de migración, las consultas y prompts objetivo, y el evento que demuestre el éxito. Revisa:

• impresiones y visitas de consultas de producto, versión, funcionalidad, obsolescencia y registro de cambios;
• citas de IA que reproduzcan la fecha de lanzamiento, el estado, el límite de compatibilidad y la acción correctos;
• visitas a anclas o páginas a nivel de entrada en lugar de solo visitas al índice del registro de cambios;
• clics en rutas de documentación actualizada, migración, solución de problemas o verificación;
• inicios de migración, finalizaciones de validación y uso heredado restante cuando exista telemetría segura para la privacidad;
• contactos de soporte causados por alcance poco claro, falta de acceso a la implementación o comportamiento no documentado;
• respuestas desactualizadas después de una corrección, retirada, lanzamiento que reemplaza al anterior o cambio de fecha límite.

Sigue cómo medimos los resultados para separar descubrimiento, citación, interacción, finalización de tareas, retención y resultados comerciales. Anota los lanzamientos, incidencias, campañas y migraciones obligatorias antes de interpretar movimientos. Un pico de tráfico puede indicar confusión, y una respuesta citada es perjudicial si omite la fecha límite del cambio drástico.

FAQ

Preguntas frecuentes