v1 is the schema major version. A manifest declares which schema version it conforms to via
the $schema field, and that value is a const — a v1 manifest must reference the v1
schema URL exactly. There is no $schema: "v1.2" — schema evolution that doesn't break existing
manifests happens withinv1 (e.g. new optional fields, new enum values). A breaking change
(removing a field, changing required-ness, changing semantics of an existing field) requires a
new major schema version — v2 — published at its own URL, so v1 manifests and tooling keep
working unmodified.
MView version — version
Each individual mview.json also carries its own semantic version:
"version": "1.0.0"
This tracks the MView itself — its parser and component — not the schema. Bump it when you
regenerate or hand-edit the parser or component in a way worth tracking. It has no bearing on
which schema the manifest validates against.
Why the URL includes the version
Publishing the schema at a versioned URL (/mview/v1/schema.json, eventually /mview/v2/...)
means:
Tooling can pin to a specific schema version and won't be broken by a future breaking change.
A manifest is self-describing — $schema tells any validator, editor, or agent exactly which
rules apply, without out-of-band coordination.
Old MViews keep validating against v1 forever, even after v2 exists.
Practical implication for implementers
If you're building a runtime or validator: resolve the schema from the manifest's own
$schema field rather than hardcoding v1. That's what makes your implementation forward
compatible with v2 manifests once they exist, without a code change.
Versionado
Cómo se versiona el esquema, en qué se diferencia de la versión de una MView individual y el esquema de URL.
Versionado
Hay dos números de versión independientes involucrados, y es fácil confundirlos.
Versión del esquema — $schema
El esquema se versiona mediante la ruta de su URL:
v1 es la versión mayor del esquema. Un manifiesto declara a qué versión de esquema se ajusta mediante el campo $schema, y ese valor es un const: un manifiesto v1 debe referenciar exactamente la URL del esquema v1. No existe $schema: "v1.2": la evolución del esquema que no rompe manifiestos existentes ocurre dentro de v1 (por ejemplo, nuevos campos opcionales, nuevos valores de enum). Un cambio incompatible (eliminar un campo, cambiar obligatoriedad, cambiar semántica de un campo existente) requiere una nueva versión mayor del esquema, v2, publicada en su propia URL, para que manifiestos y tooling v1 sigan funcionando sin modificaciones.
Versión de MView — version
Cada mview.json individual también lleva su propia versión semántica:
"version": "1.0.0"
Esto rastrea la MView en sí —su parser y componente—, no el esquema. Súbela cuando regeneres o edites a mano el parser o componente de una forma que valga la pena registrar. No afecta contra qué esquema valida el manifiesto.
Por qué la URL incluye la versión
Publicar el esquema en una URL versionada (/mview/v1/schema.json, eventualmente /mview/v2/...) significa que:
El tooling puede fijarse a una versión específica del esquema y no romperse por un cambio incompatible futuro.
Un manifiesto se describe a sí mismo: $schema le dice a cualquier validador, editor o agente exactamente qué reglas aplican, sin coordinación fuera de banda.
Las MViews antiguas siguen validando contra v1 para siempre, incluso después de que exista v2.
Implicación práctica para implementadores
Si estás construyendo un runtime o validador: resuelve el esquema desde el propio campo $schema del manifiesto, en lugar de hardcodear v1. Eso hace que tu implementación sea compatible hacia adelante con manifiestos v2 cuando existan, sin un cambio de código.