Resumen

  • recommended-min-version compara solo los números mayor, menor y de parche. La revisión 28 del borrador de YANG Semantic Versioning ordena ignorar _compatible, _non_compatible y los metadatos al decidir si un candidato alcanza el mínimo.
  • El filtro admite cualquier versión mayor y el compilador puede continuar con las reglas de RFC 7950 después de avisar que no encontró una versión válida. Por eso resolver, satisfacer la recomendación y demostrar compatibilidad son resultados distintos.
  • Antes de promover el esquema hace falta un recibo de resolución con la petición, todos los candidatos, los bytes elegidos, el conjunto completo de módulos, funciones y desviaciones, los avisos, las pruebas de clientes, el responsable y el punto de reversión. Es una propuesta editorial de Daniel Kade, no un requisito del IETF.

El número responde menos de lo que parece

La expresión “versión mínima” tiene fuerza administrativa. Puede entrar en una hoja de requisitos, en una política de seguridad o en una puerta de integración continua. Una vez allí, parece dividir el mundo en dos grupos: lo inferior es inaceptable y todo lo superior es seguro. Si además el número tiene forma semántica, la intuición añade otra regla: un salto de versión mayor será incompatible y, por tanto, el gestor de dependencias no lo cruzará por accidente.

El mecanismo propuesto para YANG reparte el trabajo de otra forma. draft-ietf-netmod-yang-semver-28 fue publicado el 21 de julio de 2026, está en la cola del RFC Editor y sigue siendo un Internet-Draft activo destinado al Standards Track. Su extensión recommended-min-version aparece bajo una sentencia import y recibe un triplete numérico. No recibe el sufijo de compatibilidad.

Cuando el resolvedor evalúa candidatos, prescinde expresamente de _compatible, _non_compatible, los datos de prelanzamiento y los de compilación. Cumple un candidato con el mismo triplete; uno con parche superior si conserva mayor y menor; uno con menor superior dentro del mismo mayor; y cualquiera con mayor superior. El propio texto demuestra la consecuencia: para 3.1.0 son aceptables 3.1.2 _non_compatible, 3.3.0-00 y 4.1.2.

La amplitud es intencionada. Los autores prefieren una regla sencilla para resolver la importación y dejan la coherencia del conjunto fuera de la extensión, citando los paquetes YANG como posible instrumento. La norma no dice “4.1.2 es compatible con 3.1.0”. Dice “4.1.2 satisface este criterio mínimo”. El salto indebido ocurre cuando el sistema de entrega borra el sustantivo “criterio” y conserva solo una luz verde.

La etiqueta de compatibilidad sigue siendo una evidencia valiosa

YANG Semver hace más legible la historia de un artefacto. En la línea principal, un cambio mayor indica una modificación no retrocompatible. Un cambio menor comunica una evolución compatible dentro del mismo mayor. Un parche sin modificador es editorial. Los modificadores especiales permiten mantener ramas antiguas y decir si el parche de esa rama conserva o rompe compatibilidad. _non_compatible queda adherido a la rama para que una edición posterior no borre la advertencia.

Además, el nombre del artefacto y su versión semántica deben identificar una revisión única. Reutilizar ambos para contenidos diferentes está prohibido. Esta regla aporta identidad y trazabilidad a la publicación de módulos.

Nada de ello convierte la etiqueta en una prueba ejecutable de cada consumidor. “Compatible” resume la intención del cambio según las reglas del autor del modelo. Un generador de código puede tener un defecto. Un controlador puede haber tratado una enumeración abierta como una lista cerrada. Una aplicación puede depender de una descripción o de un orden que nunca formó parte del contrato. La etiqueta correcta no vuelve correctas esas dependencias ocultas.

Tampoco basta la huella de un archivo aislado. El borrador advierte que un submódulo puede cambiar radicalmente de significado sin cambiar sus propios bytes o su revisión, porque otro submódulo modifica un agrupamiento o un tipo que el primero utiliza. La procedencia exacta del archivo es necesaria; la procedencia del esquema efectivo exige la composición completa.

“Resuelto” puede ocultar tres desenlaces

El primer desenlace es satisfacción numérica. Uno de los candidatos visibles cumplió las condiciones de recommended-min-version. Para reproducirlo no basta guardar el ganador: hay que guardar el inventario contra el cual compitió.

El segundo es continuación por repliegue. Si el compilador que entiende la extensión no encuentra una versión viable, el borrador dice que debería emitir un aviso y seguir las reglas establecidas por RFC 7950. En YANG 1.1, un revision-date explícito fija la revisión; sin él, no queda definida del mismo modo cuál se importa. El compilador puede terminar y entregar un esquema, pero la recomendación semántica no se convirtió mágicamente en satisfecha.

El tercero es aceptación de despliegue. El conjunto exacto se prueba con los controladores, agentes, colectores, generadores y configuraciones que dependen de él. La autoridad de cambio decide si las pruebas cubren el riesgo y si existe una reversión viable.

Una canalización que represente los tres con el mismo estado “success” pierde información institucional. La versión elegible podría romper un cliente antiguo. El repliegue podría traer una revisión anterior a la que esperaba el autor. El esquema podría compilar, pero una función recién activada cambiar los nodos visibles. El proceso no falló técnicamente; falló la descripción de lo que consiguió.

La unidad de compatibilidad es el conjunto resuelto

RFC 8525 describe el contexto que falta en el número. Un esquema de almacén de datos se compone de conjuntos de módulos. Cada conjunto enumera módulos implementados, módulos usados solo para importar, submódulos, funciones admitidas y módulos de desviación. YANG Library cambia su content-id cuando cambia ese contenido.

Las funciones y desviaciones importan porque dos servidores con el mismo módulo base pueden exponer superficies distintas. Una desviación puede limitar o eliminar un nodo. Una función puede abrir una rama que el cliente nunca vio. Un módulo solo de importación puede cambiar el tipo efectivo que se propaga a otros modelos. Decir que “el módulo X está en 4.1.2” no identifica todo aquello que el cliente interpreta.

El borrador de YANG Packages permite dar nombre y versión a una estructura jerárquica de módulos. Un paquete puede incluir otros paquetes, módulos implementados o de importación, y funciones; también puede excluir elementos heredados. Cuando dos paquetes proponen revisiones diferentes, las reglas pueden elegir automáticamente una más reciente. El patrón es útil para aplicar un hotfix, aunque una selección automática sigue siendo una decisión que debe quedar visible.

Los paquetes no son necesariamente completos. El borrador contempla paquetes incompletos para hotfixes o agrupaciones lógicas y permite que parte de la resolución ocurra en el entorno que los usa. Cuando los paquetes se vinculan con un esquema anunciado, la resolución, incluidas las funciones adicionales, debe coincidir exactamente con el module-set de YANG Library y ser referencialmente completa. Esa coincidencia certifica el conjunto anunciado. No ejecuta un solo camino del cliente.

La diferencia de esquema no es la consecuencia para el cliente

El trabajo de comparación de esquemas puede describir de forma estructurada qué cambió entre dos revisiones. Es una defensa contra la revisión superficial basada en el número de versión. Permite localizar instrucciones modificadas y conservar una clasificación de la diferencia.

Su límite es igual de importante. El comparador no sabe cómo una versión concreta de un controlador generó sus tipos. No conoce las validaciones privadas de una aplicación, los supuestos de un script ni el efecto de una notificación adicional sobre una máquina de estados. Tampoco demuestra que un rollback restaure a la vez modelo, código generado, configuración persistida y estado del dispositivo.

La compatibilidad siempre tiene dos extremos. Debe nombrarse el esquema resuelto y el consumidor. También deben nombrarse la carga y los casos utilizados. Una afirmación como “el diff es compatible” es incompleta sin la base comparada, la política de clasificación y la población de clientes cuya conducta fue observada.

Un recibo de resolución conserva lo que el algoritmo descarta

El recibo de resolución comienza por el módulo que importa: nombre, revisión, versión semántica completa, huella y ubicación. Copia literalmente el triplete solicitado. Después registra todos los candidatos que el resolvedor pudo ver, con sus versiones completas, ubicaciones y huellas. Si la regla ignora _non_compatible para ordenar, el recibo debe conservarlo para gobernar.

El ganador se fija mediante bytes exactos o una huella estable, fecha de revisión, versión y procedencia. Luego se expande el conjunto: paquetes incluidos, exclusiones, módulos implementados, importaciones, submódulos, funciones, desviaciones, puntos de montaje y content-id. El recibo declara si cada paquete era completo, qué dependencias se resolvieron localmente y qué regla decidió un conflicto.

El compilador también tiene identidad. Deben guardarse su versión, sus avisos y el camino tomado. “Satisfizo semver” y “continuó por RFC 7950” no son equivalentes. Si se generó una comparación, se conserva la base y el criterio con los que se produjo.

El último bloque pertenece al despliegue: versiones de clientes, configuraciones representativas, operaciones, notificaciones y rutas de estado ensayadas; resultados negativos; propietario de la decisión; ámbito y fecha de caducidad; conjunto anterior que puede restaurarse. Una prueba de laboratorio no se hereda automáticamente por todos los consumidores de un repositorio común.

El recibo no complica el estándar. Hace algo más sobrio: impide que la institución use la sencillez del estándar como sustituto de sus propias decisiones.

Fuentes