Résumé

  • Dans la révision 28 du projet YANG Semantic Versioning, recommended-min-version ne compare que le triplet majeur, mineur et correctif. Les suffixes _compatible, _non_compatible et les métadonnées sont écartés du calcul.
  • Une version majeure supérieure peut donc satisfaire la recommandation, tout comme une révision explicitement marquée non compatible. En cas d’échec, le compilateur peut avertir puis poursuivre avec les règles de la RFC 7950 : « schéma produit » et « recommandation satisfaite » sont deux états différents.
  • Il faut lier la résolution à une preuve de résolution : demande initiale, candidats visibles, octets retenus, ensemble complet de modules, fonctions et déviations, avertissements, essais des clients, responsable de la décision et cible de retour arrière. Cette proposition est celle de Daniel Kade, pas une exigence de l’IETF.

Le piège ne se trouve pas dans l’algorithme, mais dans son interprétation

Dans une réunion de changement, « version minimale 3.1.0 » sera volontiers reformulé ainsi : « tout ce qui est plus récent convient ». La phrase est courte, familière et faussement rassurante. Elle importe dans YANG une convention implicite de l’univers logiciel : le numéro majeur signalerait certes les ruptures, mais un gestionnaire de dépendances empêcherait normalement de les franchir sans une demande explicite.

Le projet draft-ietf-netmod-yang-semver-28 adopte une autre répartition des responsabilités. Publiée le 21 juillet 2026, cette version est un Internet-Draft actif destiné à la voie Standards Track et placé dans la file du RFC Editor ; elle n’est pas encore une RFC. L’extension recommended-min-version, attachée à une instruction import, reçoit uniquement trois nombres. Pour sélectionner un module, elle ignore volontairement les qualificatifs de compatibilité et les informations de prépublication ou de construction.

La logique accepte le même triplet, un correctif supérieur dans la même branche majeure et mineure, une version mineure supérieure dans la même branche majeure, ou n’importe quelle version majeure supérieure. L’exemple normatif est particulièrement utile : pour 3.1.0, 3.1.2 _non_compatible et 4.1.2 sont tous deux admissibles. Dans le premier cas, le suffixe dit précisément qu’une rupture a eu lieu dans la branche. Dans le second, la hausse du numéro majeur joue ce rôle. La comparaison voit les chiffres, pas l’avertissement.

Le texte ne cache pas ce résultat. Il explique que ce choix garde la résolution simple et que la cohérence de l’ensemble des modules doit être assurée en dehors de l’extension, par exemple au moyen de paquets YANG. Autrement dit, le filtre répond à une question étroite : un candidat est-il numériquement au moins égal à la recommandation ? Il ne répond pas à la question que l’équipe d’exploitation veut souvent lui confier : ce candidat préservera-t-il les hypothèses de nos contrôleurs ?

Le signal de version garde toute sa valeur

Refuser d’en faire un certificat ne diminue pas l’intérêt de YANG Semver. Le schéma de version rend visibles les intentions de l’auteur. Une variation majeure indique une modification non rétrocompatible sur la lignée principale. Une variation mineure décrit normalement une évolution rétrocompatible dans une même branche majeure. Un correctif sans suffixe correspond à une modification éditoriale. Les suffixes propres à YANG permettent en outre d’entretenir des branches anciennes sans les faire passer pour une seule suite linéaire.

Le caractère persistant de _non_compatible est une bonne discipline. Une rupture introduite dans une branche ne disparaît pas du regard simplement parce qu’une correction éditoriale lui succède. Le couple nom de l’artefact et version sémantique doit aussi désigner une révision unique : deux contenus différents ne peuvent légitimement réutiliser le même couple.

Ces propriétés organisent la provenance intellectuelle d’un module. Elles ne testent pas un consommateur. Un ajout officiellement rétrocompatible peut révéler une hypothèse fragile dans un générateur de code. Une nouvelle identité peut être valide selon le modèle et néanmoins casser un client qui avait fermé une liste que le langage laissait ouverte. Une variation purement éditoriale modifie les octets et peut déclencher une politique de chaîne d’approvisionnement trop rigide. La compatibilité réelle reste une relation entre le schéma résolu et un client déterminé.

Le cas des sous-modules montre pourquoi le numéro d’un seul fichier ne suffit pas. Le projet précise que le sens d’un sous-module peut être profondément modifié sans que son propre contenu change : un autre sous-module peut avoir changé un typedef ou un groupement qu’il utilise. L’empreinte du fichier est exacte, mais l’objet effectivement interprété dépend du contexte d’inclusion.

Trois feux verts qu’il faut séparer

Une chaîne de livraison devrait afficher trois décisions, non un seul voyant.

Le premier état est la satisfaction de la recommandation. Le résolveur a trouvé un candidat conforme à l’ordre numérique défini par YANG Semver. C’est un résultat reproductible si l’inventaire des candidats est lui-même conservé.

Le deuxième est l’achèvement par repli. Si aucun module viable n’est trouvé, le projet recommande au compilateur d’émettre un avertissement puis de poursuivre selon les règles établies par la RFC 7950. Celle-ci permet de demander une révision précise par revision-date; sans ce choix explicite, la révision importée n’est pas définie par le langage de la même manière. Un schéma peut donc être produit après un échec du critère semver. Transformer cette sortie en succès global efface l’information la plus importante du processus.

Le troisième état est l’acceptation pour le déploiement. Ici, le schéma exact est confronté aux contrôleurs, collecteurs, générateurs, configurations et pratiques de retour arrière qui en dépendront. Ce verdict n’appartient ni au numéro, ni au compilateur seul.

Les écarts entre les trois sont normaux. Un module admissible peut être illisible pour une ancienne bibliothèque. Un repli peut aboutir à une révision syntaxiquement correcte mais antérieure à la dépendance attendue par l’auteur. Une composition peut compiler tandis qu’une fonction activée fait apparaître des nœuds inconnus d’un client. La bonne gouvernance commence par la conservation de ces différences.

L’unité à contrôler est le schéma résolu

La RFC 8525 élargit correctement le cadre. Une vue de données dépend d’un schéma, et ce schéma est l’union d’ensembles de modules. Un ensemble recense les modules mis en œuvre, les modules utilisés uniquement pour les imports, leurs sous-modules, les fonctions prises en charge et les modules de déviation. Le content-id de YANG Library change lorsque ce contenu change.

Ainsi, remplacer une seule révision ne décrit pas toute la transition. Une déviation peut retirer ou contraindre un nœud que le module de base continue d’afficher. Une fonction activée peut ouvrir une branche absente dans l’environnement précédent. Un module d’import peut modifier le type effectif employé par plusieurs autres modules. La compatibilité doit porter sur cette composition.

Le projet YANG Packages offre une structure versionnée pour nommer et résoudre de telles compositions. Un paquet peut inclure d’autres paquets, des modules mis en œuvre ou réservés à l’import, ainsi que des fonctions ; il peut aussi exclure des éléments hérités. Les conflits peuvent conduire automatiquement à retenir une version ultérieure, ce qui facilite la distribution d’un correctif. Pour imposer une version plus ancienne, il faut une composition explicite qui affine les paquets de départ.

Ce mécanisme rapproche la résolution d’un ensemble cohérent, mais il ne délivre pas de garantie universelle. Le projet autorise des paquets incomplets pour des correctifs ou des regroupements logiques. Des dépendances restent alors à résoudre dans le contexte local. Lorsqu’un paquet est lié à un schéma de magasin de données, sa résolution et les fonctions supplémentaires doivent correspondre exactement à l’ensemble déclaré par YANG Library et être référentiellement complètes. Cela prouve une propriété de composition, pas le comportement d’un logiciel client.

Comparer deux schémas n’exécute aucun contrôleur

Le projet consacré à la comparaison de schémas apporte une brique supplémentaire. Il permet de décrire de manière structurée les différences entre deux versions. Une revue peut enfin regarder les instructions qui ont changé plutôt que de déduire toute la portée d’un seul nombre.

Mais une différence classée comme rétrocompatible reste une description du modèle. L’outil ne connaît pas la génération de code d’une entreprise, les validations supplémentaires d’un produit, les raccourcis d’un script ni la manière dont un contrôleur réagit à une notification inconnue. Il ne rejoue pas les configurations représentatives et ne vérifie pas la restauration simultanée du schéma, du code généré et de l’état du réseau.

Il faut donc énoncer le sujet de chaque preuve. La comparaison atteste un changement entre deux schémas selon une méthode donnée. Un essai client atteste le comportement d’une version nommée de ce client sur un ensemble de cas. Un déploiement pilote atteste ce qui a été observé dans un périmètre. Aucun de ces résultats ne peut être étendu silencieusement aux autres.

La preuve de résolution remet les responsabilités dans l’ordre

Une preuve de résolution doit commencer par l’importateur : nom du module, révision, version complète, empreinte du contenu et emplacement d’origine. Elle recopie la recommandation numérique exacte. Elle conserve ensuite tous les candidats visibles, avec leurs chaînes de version complètes, leurs emplacements et leurs empreintes. Le résolveur peut ignorer un suffixe pour calculer ; l’audit, lui, ne doit pas l’oublier.

Pour le gagnant, la preuve retient les octets ou une empreinte stable, la date de révision, la version et la provenance de récupération. Elle déroule ensuite l’ensemble complet : paquets inclus, exclusions, modules mis en œuvre, imports seuls, sous-modules, fonctions, déviations, points de montage et content-id. Elle indique quels paquets étaient complets, quelles dépendances ont été résolues localement et quelle règle a tranché chaque conflit.

Le comportement de l’outil est une donnée de gouvernance. La preuve nomme le compilateur et sa version, garde les avertissements et distingue le succès du critère semver d’un repli RFC 7950. Si une comparaison de schémas a été exécutée, elle en indique la base, la politique et le résultat.

Enfin viennent les consommateurs. La preuve identifie chaque contrôleur, agent, générateur ou collecteur testé, les configurations, RPC, notifications et chemins d’état représentatifs, ainsi que les échecs connus. Elle nomme la personne qui accepte l’incertitude restante, le périmètre autorisé et l’ensemble exact qui servira au retour arrière. Une approbation destinée au laboratoire ne devient pas une autorisation générale parce que les modules partagent un dépôt.

Le projet de standard peut alors rester simple. Ce n’est pas à une instruction d’import de gouverner toute une migration. C’est à l’organisation de ne pas attribuer à cette instruction une promesse qu’elle n’a jamais faite.

Sources