Resumo

  • recommended-min-version considera apenas os números principal, secundário e de correção. A revisão 28 do rascunho de YANG Semantic Versioning ignora _compatible, _non_compatible e metadados na comparação.
  • Uma versão principal maior pode satisfazer a recomendação. Se nenhuma candidata viável for encontrada, o compilador pode avisar e seguir com as regras da RFC 7950; portanto, concluir a resolução não demonstra que a recomendação foi atendida.
  • Antes da implantação, é preciso produzir um recibo de resolução com pedido, candidatas, informação descartada, bytes escolhidos, conjunto completo, recursos, desvios, avisos, testes de clientes, responsável e alvo de reversão. A proposta é de Daniel Kade, não uma obrigação do IETF.

Uma palavra administrativa sobrecarrega uma regra técnica

“Mínima” costuma designar uma barreira. Uma política de segurança define a versão mínima porque tudo abaixo dela é proibido. Um edital define uma capacidade mínima porque ofertas superiores são aceitas. Quando a mesma palavra aparece junto de três números semânticos, é fácil supor que qualquer valor maior preserva o que o importador precisa, salvo uma exceção claramente bloqueada pelo gerenciador de dependências.

O draft-ietf-netmod-yang-semver-28 não distribui as garantias dessa forma. Publicada em 21 de julho de 2026, a revisão 28 é um Internet-Draft ativo, destinado ao Standards Track e na fila do RFC Editor; ainda não é RFC. A extensão recommended-min-version fica sob uma instrução import e recebe somente o trio numérico.

A candidata é admissível se repetir os três números, elevar o patch com principal e secundário iguais, elevar o secundário dentro do mesmo principal ou elevar o principal. A comparação desconsidera os modificadores de compatibilidade e os metadados de pré-lançamento e construção. O próprio exemplo do rascunho elimina qualquer dúvida: diante de 3.1.0, tanto 3.1.2 _non_compatible quanto 4.1.2 satisfazem a recomendação.

O resultado é deliberado. O texto quer uma resolução simples e diz que a responsabilidade por um conjunto coerente de versões fica fora da extensão, citando os pacotes YANG como mecanismo possível. A regra responde se uma versão está numericamente dentro do espaço permitido. Não responde se um controlador concreto preservará seu comportamento.

O erro de governança surge quando a interface mostra apenas “minimum satisfied”. A frase técnica correta atravessa um sistema de aprovação e chega à produção como “compatibilidade verificada”, embora nenhum ator tenha realizado essa verificação.

A versão semântica é uma declaração útil, não um ensaio

YANG Semver melhora a legibilidade da evolução dos modelos. Uma mudança principal comunica alteração não retrocompatível na linha central. Uma mudança secundária normalmente representa acréscimo retrocompatível dentro do mesmo principal. Um patch sem modificador é editorial. Os sufixos específicos de YANG permitem manter ramos antigos, e _non_compatible permanece no ramo para que uma edição posterior não apague o aviso de ruptura.

O par formado pelo nome do artefato e pela versão semântica também deve identificar uma única revisão. Conteúdos diferentes não podem reutilizar o mesmo par. Essa exigência organiza identidade e proveniência de publicação.

Ainda assim, a etiqueta descreve a intenção do autor sob uma política, não o resultado de todos os consumidores. Um acréscimo retrocompatível pode quebrar um cliente que tratou uma enumeração extensível como fechada. Um nó novo pode revelar um bug no gerador de código. Uma aplicação pode depender de uma ordem ou descrição que jamais foi contrato. A classificação correta do modelo não corrige pressupostos incorretos do software que o consome.

Nem a identidade de um único arquivo fecha a questão. O rascunho observa que o significado de um submódulo pode mudar radicalmente sem mudança no próprio conteúdo ou na revisão, porque outro submódulo alterou um agrupamento ou tipo usado por ele. O hash comprova o arquivo recebido; não comprova sozinho o schema efetivo montado pelo módulo que o inclui.

Por isso, a versão deve ser tratada como evidência estruturada da linhagem declarada pelo autor. Não é hash criptográfico, arquivo de lock, resultado de conformidade nem autorização de mudança.

Há três tipos de “resolução bem-sucedida”

O primeiro é a satisfação da recomendação. Uma candidata visível passou pelas regras numéricas. Para reproduzir o resultado, é necessário guardar todo o conjunto de candidatas daquele momento, não apenas a vencedora. Uma nova versão no repositório pode mudar a escolha sem alterar o módulo importador.

O segundo é a conclusão por fallback. Se o compilador que entende a extensão não localizar versão viável, o rascunho orienta a emissão de um aviso e a continuidade pelas regras da RFC 7950. Nela, revision-date permite fixar uma revisão; sem essa indicação, a linguagem não define da mesma maneira qual revisão será usada. O compilador pode entregar um schema após o aviso. Isso não transforma a falha da recomendação em sucesso.

O terceiro é a aceitação para implantação. O conjunto exato é testado contra controladores, agentes, coletores, geradores, configurações e fluxos operacionais reais. O dono da mudança avalia cobertura, incerteza restante e reversão.

Os três resultados podem divergir. Uma versão numericamente elegível pode não ser analisada por uma biblioteca antiga. O fallback pode escolher um typedef anterior ao esperado pelo autor. O schema pode compilar enquanto um recurso ativado altera a superfície oferecida ao cliente. Uma única luz verde impede que a instituição distinga busca, compilação e segurança operacional.

O objeto da compatibilidade é o schema resolvido inteiro

A RFC 8525 oferece a moldura mais ampla. Cada datastore possui um schema, e cada schema é a união de conjuntos de módulos. Esses conjuntos incluem módulos implementados, módulos exclusivos para importação, submódulos, recursos suportados e módulos de desvio. Quando o conteúdo da YANG Library muda, o content-id muda.

Dois ambientes com a mesma revisão do módulo-base podem, portanto, apresentar superfícies diferentes. Um desvio pode retirar ou restringir um nó esperado. Um recurso pode abrir uma ramificação nova. Um módulo importado apenas por seus tipos pode propagar uma mudança a diversos modelos. Registrar somente a versão vencedora recorta o verdadeiro objeto de decisão.

O rascunho YANG Packages organiza esse conjunto como uma estrutura hierárquica versionada. Um pacote pode incluir outros pacotes, módulos implementados, módulos exclusivos de importação e recursos, e pode excluir itens herdados. Em conflitos, regras automáticas podem selecionar uma versão posterior, facilitando um hotfix. Para escolher uma versão anterior, é necessário criar uma composição explícita que refine os pacotes referenciados.

Essa estrutura fortalece a coerência, mas o nome e a versão do pacote não são certificado universal. Pacotes incompletos são permitidos para hotfixes e agrupamentos lógicos; parte das dependências pode ser decidida no ambiente. Quando os pacotes se vinculam a um schema anunciado, a resolução, com recursos adicionais, deve coincidir exatamente com o module-set da YANG Library e ser referencialmente completa. É uma prova sobre composição, não sobre execução do cliente.

Comparar schemas não reproduz o impacto

O trabalho de YANG Schema Comparison fornece uma forma legível por máquina de descrever diferenças entre schemas. Isso permite examinar as instruções alteradas em vez de inferir tudo de um número. É uma etapa importante da revisão.

Mas o comparador não executa bindings gerados. Não sabe que um script presume a presença constante de uma folha, que um coletor rejeita uma identidade desconhecida ou que um controlador responde a uma notificação nova com repetição destrutiva. Também não garante que uma reversão recupere simultaneamente modelo, código gerado, configuração persistida e estado do equipamento.

Compatibilidade é relação. É preciso nomear o schema resolvido, o consumidor, a versão do consumidor, a carga e os pressupostos examinados. “Comparação aprovada” é insuficiente sem o schema-base, a política de classificação e os clientes realmente testados.

O recibo de resolução preserva a decisão real

O recibo de resolução começa pelo módulo que importa: nome, revisão, versão completa, hash e origem. Copia o trio solicitado. Em seguida lista todas as candidatas visíveis com cadeia de versão completa, localização e hash. A regra pode ignorar _non_compatible para ordenar; a governança precisa preservá-lo.

Para a selecionada, ficam os bytes exatos ou digest estável, data de revisão, versão e proveniência de obtenção. O registro então se abre para o conjunto inteiro: pacotes incluídos e excluídos, módulos implementados e de importação, submódulos, recursos, desvios, contexto de montagem e content-id. Declara quais pacotes eram completos, quais dependências foram resolvidas localmente e qual regra venceu cada conflito.

O caminho da ferramenta também integra a evidência. Nome e versão do compilador, avisos e fallback são preservados. “Atendeu a semver” não pode ser confundido com “continuou por RFC 7950”. Uma comparação de schemas vem acompanhada de sua base, política e resultado.

Por fim aparecem os consumidores: versões de controlador, agente, gerador e coletor; configurações, RPCs, notificações e caminhos de estado representativos; falhas; incertezas aceitas; responsável pela decisão; alcance e validade da aprovação; conjunto exato de rollback. Um teste de laboratório não concede autorização automática a todos os clientes que consultam o mesmo repositório.

O recibo não pede que uma pequena extensão resolva toda a governança de mudança. Ele impede apenas que responsabilidades externas sejam esquecidas depois que a comparação numérica termina.

Fontes