La identidad de versión tiene más de un significado

1311. Identidad de la lección

Módulo

3.13 — Versionado del esquema y del build

Lección

La identidad de versión tiene más de un significado

Tipo académico

Concepto

Tipo de esquema

texto

Orden

Lección 1 del módulo

Tiempo estimado

30–45 minutos, incluida la práctica

1312. Objetivo de aprendizaje

Al finalizar esta lección, podrás seleccionar la identidad de versión correcta en cuatro situaciones: interpretar datos, identificar un build ejecutable, identificar un conjunto de contenido y rastrear un cambio en el control de código fuente.

1313. Por qué importa

Una etiqueta como v2 no es suficientemente precisa para responder todas las preguntas de producción. Un esquema puede seguir siendo compatible mientras cambia el ejecutable, y el contenido puede cambiar sin que cambie el formato de los datos. Si mezclas estas identidades, un asistente de IA puede diagnosticar la capa equivocada o recomendar una migración inválida. Separarlas te proporciona un lenguaje fiable para las comprobaciones de compatibilidad, las notas de versión, la depuración y las decisiones de rollback.

1314. Conocimientos previos

Ya debes poder describir una verificación de integración en términos de propiedad, configuración, modo de prueba, comportamiento ante fallos y evidencia. Esta lección parte de 3.12 L2 — Escribir una verificación de integración sin secretos y aplica la misma disciplina basada en evidencia a la identidad de versión.

1315. Concepto central

“Versión” es una familia de identidades, no un único número universal. Hay que distinguir cuatro dimensiones:

Estas identidades pueden estar relacionadas sin ser intercambiables. Un build puede empaquetar un commit específico y un manifiesto de contenido concreto mientras utiliza un esquema antiguo. Del mismo modo, dos builds pueden usar el mismo esquema y contenido, pero diferir en el código.

La compatibilidad también depende de la dimensión. Una afirmación de compatibilidad de esquema se refiere a lectores y escritores de datos. Una afirmación de compatibilidad del build se refiere al artefacto de ejecución y a su entorno. Una afirmación de compatibilidad del contenido se refiere a si ese conjunto puede ser cargado y utilizado por el build. La identidad del control de código fuente aporta trazabilidad; por sí sola no demuestra que el artefacto resultante se haya empaquetado correctamente.

1316. Modelo mental

Utiliza el filtro de cuatro preguntas sobre la versión antes de elegir una identidad:

1. ¿Qué se está interpretando? Elige la versión del esquema cuando el tema sea la forma de los datos, los campos, la codificación o la migración.
2. ¿Qué se está ejecutando? Elige la versión del build cuando el tema sea un ejecutable empaquetado o un artefacto desplegable.
3. ¿Qué se creó o se incluyó? Elige la versión del contenido cuando el tema sean reglas, recursos, niveles, ajustes o datos de configuración.
4. ¿Qué estado exacto del proyecto debe inspeccionarse o reproducirse? Elige la identidad del control de código fuente cuando el tema sea un commit, tag o estado del repositorio.

Un registro útil puede mostrar explícitamente las relaciones:

Build:        build-0.8.4
Estado fuente: commit 7f3c1a2
Esquema:      save-schema-3
Contenido:    content-set-17

Léelo como un registro de trazabilidad, no como cuatro afirmaciones que compiten para decir que todo el juego es simplemente “versión 3”.

1317. Ejemplo concreto

Imagina un informe de prueba que dice: “Los datos del inventario fallaron después de la actualización”. La frase está incompleta. Aplica el filtro:

• Si el registro de un objeto contiene un campo que el lector no reconoce, investiga la versión del esquema y su regla de migración o compatibilidad.
• Si el tester necesita identificar el ejecutable exacto que produjo el error, registra la versión del build.
• Si el comportamiento fue causado por un nuevo ajuste de balance o una nueva definición de objeto, registra la versión del contenido.
• Si un ingeniero necesita inspeccionar la implementación exacta que generó el build, registra la identidad del control de código fuente.

Por tanto, un informe preciso podría identificar las cuatro dimensiones y asignar a cada una una función distinta: el artefacto que falló fue build-0.8.4, construido desde el estado fuente 7f3c1a2, leyendo save-schema-3 y cargando content-set-17. El informe no supone que cambiar una de estas identidades cambie automáticamente las demás.

1318. Error común

El error común consiste en tratar un número de build, un número de esquema, una etiqueta de contenido y un identificador de commit como si fueran intercambiables porque aparecen en la misma nota de versión. El número de build indica qué artefacto se ejecutó; no indica si un formato de guardado es compatible. Un commit identifica el historial del código; no demuestra qué archivos de contenido se empaquetaron. Cuando una pregunta de compatibilidad sea ambigua, nombra primero el objeto cuya identidad necesitas y después registra explícitamente esa dimensión.

1319. Práctica guiada

Clasifica la identidad de versión principal en cada situación. Escribe una frase que explique tu elección.

1. Un cargador debe decidir si puede leer un registro guardado que contiene un campo nuevo.
2. Un tester informa de un defecto y debe identificar el ejecutable exacto utilizado.
3. Un diseñador quiere comparar dos conjuntos de ajustes de enemigos y datos de encuentros.
4. Un ingeniero necesita inspeccionar el estado exacto del código desde el que se produjo un artefacto de prueba.

Después, completa este registro de trazabilidad usando etiquetas distintas en lugar de un único campo genérico version:

Build: ____________________
Estado fuente: _____________
Esquema: ____________________
Contenido: __________________

Para cada campo, indica qué evidencia respaldaría su valor. No inventes un valor si la evidencia no está disponible: márcalo como desconocido e identifica la evidencia que falta.

1320. Validación / evidencia

1321. Ideas clave

• La identidad de versión depende de qué objeto se está identificando.
• La versión del esquema responde preguntas sobre interpretación y migración de datos.
• La versión del build responde qué artefacto ejecutable se utilizó.
• La versión del contenido identifica conjuntos de datos creados y de configuración.
• La identidad del control de código fuente proporciona trazabilidad precisa, pero no sustituye la evidencia del artefacto ni de la compatibilidad.

1322. Próxima lección

A continuación: 3.13 L2 — Diseñar una matriz de compatibilidad

1323. Siguiente lección

Continúa con 3.13 L2 — Diseñar una matriz de compatibilidad.

1324. Comprobación