> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Versionado **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-002 **Título:** Estándar de arquitectura de meta-modelos - estrategia de versionado **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS-Core **Referencias informativas:** Naming-Conventions, MMAS-Package **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define la estrategia de versionado para todas las especificaciones del Meta-Universo, los Meta-Modelos y los artefactos semánticos relacionados. El objetivo es permitir una evolución continua preservando la estabilidad semántica, la interoperabilidad y la trazabilidad. --- # 2. Alcance Esta especificación se aplica a: - estándares del Meta-Universo - Meta-Modelos - Bundles - Capas - Esquemas - Objetos - Proyecciones - Contratos - Perfiles de federación Toda versión DEBERÁ declararse explícitamente. --- # 3. Principios de versionado El versionado DEBERÁ: - ser explícito; - ser inmutable tras la publicación; - preservar la trazabilidad; - admitir la coexistencia de múltiples versiones; - distinguir los cambios semánticos de los editoriales. Ninguna versión publicada DEBERÁ modificarse en silencio. --- # 4. Versionado independiente Cada elemento arquitectónico DEBERÁ tener su propio ciclo de vida y su propia versión. Algunos ejemplos: - Especificación del Meta-Universo - MUC - MMAS - MUFP - Meta-Modelo - Bundle - Capa - Esquema - Perfil de proyección - Contrato Actualizar un elemento NO DEBERÁ exigir cambiar versiones no relacionadas. --- # 5. Versionado semántico Las especificaciones DEBERÍAN seguir el versionado semántico. MAJOR : Cambios semánticos rupturistas. MINOR : Nuevas capacidades compatibles. PATCH : Correcciones editoriales, aclaraciones y mejoras no semánticas. Las implementaciones PUEDEN adoptar esquemas internos compatibles siempre que se preserve el significado semántico. --- # 6. Identidad de la versión Todo artefacto versionado DEBERÁ declarar: - identificador; - versión; - fecha de publicación; - estado; - propietario; - declaración de compatibilidad. --- # 7. Huella semántica El número de versión declara la *intención*; la **huella semántica** declara la *identidad del significado*. Cada versión publicada de un meta-modelo DEBERÁ llevar una huella semántica calculada sobre la **estructura semántica normalizada** del modelo (sus Objetos, Propiedades, Relaciones, Eventos, Contratos y Proyecciones tal como los define [MMAS-Core](MMAS-Core.md)) y NO sobre el Markdown, el orden de los archivos, los espacios en blanco u otra presentación. La huella DEBERÍA ser un resumen criptográfico (por ejemplo `sha256`) de una forma canónica y serializada de manera determinista de la estructura semántica. Dos artefactos cuyo significado sea idéntico DEBERÁN producir la misma huella aunque su formato difiera; cualquier cambio de significado DEBERÁ producir una huella distinta. Un artefacto versionado DEBERÍA declarar su huella junto a su identidad de versión: ```text Version 2.1.0 Semantic Fingerprint sha256: 8D4A...F27C ``` La huella semántica sirve a varios propósitos: - **detección de equivalencia semántica** - confirmar que dos artefactos significan lo mismo con independencia del formato o de diferencias editoriales; - **detección de incompatibilidades ocultas** - revelar cambios de significado que el número de versión no reflejó (por ejemplo, una versión PATCH cuya huella cambió); - **comprobación de compatibilidad previa a la federación** - comparar huellas antes de federar para decidir si hace falta negociación o correspondencia; - **grafos de dependencias y migraciones** - usar las huellas como nodos estables al construir grafos de dependencias de versión y migraciones en una federación. La huella DEBERÁ ser reproducible: cualquier implementación conforme, dada la misma estructura semántica, DEBERÁ calcular el mismo valor. La serialización canónica exacta, la separación entre campos semánticos y no semánticos y el procedimiento de hash se definen normativamente en [MMAS-Interchange (MUIF)](MMAS-Interchange.md), con un ejemplo resuelto verificado y una implementación de referencia. La huella semántica se combina con el [nombre semántico canónico](Naming-Conventions.md) para identificar un concepto tanto por nombre estable como por significado estable, y es uno de los campos de metadatos que transporta un [Paquete de distribución semántica](MMAS-Package.md). --- # 8. Compatibilidad Toda versión publicada DEBERÁ indicar su compatibilidad con las versiones anteriores. La compatibilidad DEBERÍA clasificarse como: - Totalmente compatible - Compatible hacia atrás - Compatible hacia delante - Requiere migración - Rupturista --- # 9. Coexistencia Varias versiones PUEDEN coexistir simultáneamente. Las implementaciones DEBERÍAN admitir negociación explícita de versiones siempre que la federación involucre versiones distintas. --- # 10. Obsolescencia Los artefactos DEBERÍAN declararse obsoletos antes de su eliminación. Un aviso de obsolescencia DEBERÁ identificar: - el artefacto obsoleto; - su sustituto; - la versión de declaración de obsolescencia; - la versión prevista de eliminación. --- # 11. Migración Los cambios rupturistas DEBERÁN incluir orientación de migración. La documentación de migración DEBERÍA describir: - los conceptos afectados; - las diferencias semánticas; - las transformaciones necesarias; - la estrategia de compatibilidad; - ejemplos. --- # 12. Estándares importados Los estándares semánticos importados DEBERÁN preservar sus identificadores de versión originales. Las extensiones locales DEBERÁN mantener una correspondencia explícita entre las versiones importadas y las extensiones locales. --- # 13. Preservación histórica Las versiones históricas DEBERÁN seguir siendo identificables y reproducibles. Las versiones anteriores DEBERÍAN seguir estando públicamente disponibles siempre que sea posible. Las versiones históricas NO DEBERÁN reescribirse. --- # 14. Negociación de versiones Los universos federados DEBERÍAN declarar las versiones admitidas durante el descubrimiento de capacidades. Si se detectan versiones incompatibles, las implementaciones DEBERÍAN: - negociar una versión compatible; - aplicar correspondencias semánticas; - solicitar una migración; - o rechazar la federación. --- # 15. Invariantes arquitectónicos Los cambios de versión NUNCA DEBERÁN invalidar: - la identidad global; - la propiedad; - la procedencia; - la trazabilidad; - el cumplimiento constitucional. Estos invariantes se rigen por la MUC. --- # 16. Direcciones futuras La huella semántica habilita una visión de la evolución guiada por huellas que trabajos futuros podrían normalizar como un **Estándar de migración semántica (SMS)**. Ese estándar trataría las huellas como los nodos canónicos de un grafo de dependencias de versión y migraciones de alcance federativo, definiría cómo se asocian las transformaciones de migración a pares de huellas y especificaría cómo los universos que negocian seleccionan automáticamente una ruta de migración. El propio cálculo de la huella podría además merecer un pequeño perfil complementario que fije el procedimiento de normalización y serialización para que toda implementación produzca resúmenes idénticos byte a byte. --- # Declaración final El versionado en el Meta-Universo existe para preservar la continuidad semántica. La evolución se fomenta, pero todo cambio debe seguir siendo explícito, trazable, compatible siempre que sea practicable y comprensible tanto por personas como por sistemas de IA.