search

Found

info Visão geral

Analisa duas versões por SemVer 2.0.0 em major / minor / patch / pre-release e devolve um veredito estrito de precedência A < B / A = B / A > B.

📘 Como usar

  1. Digite a primeira string de versão no campo Versão A
  2. Digite a segunda string de versão no campo Versão B
  3. Veja o símbolo do resultado e a decomposição de major / minor / patch / pre-release / build

Comparador de Versões SemVer

※ A comparação segue as regras de precedência de SemVer 2.0.0 (https://semver.org/).

※ A metadata de build (após +) é ignorada na comparação de precedência.

Resultado

Componentes de A

major
minor
patch
pre-release
build

Componentes de B

major
minor
patch
pre-release
build
Copiado
Article

Comparador de Versões SemVer | Descubra qual versão é mais recente conforme SemVer 2.0.0

Analisa duas strings de versão pela especificação SemVer 2.0.0, separa em major / minor / patch / pre-release / build e devolve um veredito estrito de precedência. Casos como 1.2.3 contra 1.10.0-rc.1 ficam transparentes com um símbolo e a decomposição dos componentes.

💡 Sobre esta ferramenta

Comparar versões não é o mesmo que ordenar texto. Se você comparar 1.9.0 e 1.10.0 como strings comuns, o 9 parece maior que o 1, então 1.9.0 venceria, o que está errado. O SemVer compara o campo minor de forma numérica, portanto 1.10.0 é a versão mais recente. Essa pegadinha do «9 contra 10» é justamente o que confunde ao revisar o diff de um lockfile ou ao decidir se uma atualização é segura.

Cole duas versões e a ferramenta analisa cada uma, compara major / minor / patch como números inteiros e depois aplica as regras de precedência de pre-release, devolvendo A < B, A = B ou A > B. Cada versão é decomposta em seus componentes num cartão vertical para você ver por que o veredito saiu daquele jeito. Os metadados de build (tudo após o +) são ignorados na precedência conforme a especificação, e a decomposição mostra isso com clareza.

🧐 Perguntas frequentes

1.0.0-alpha é mais antiga ou mais recente que 1.0.0? 1.0.0 é mais recente. Uma versão pre-release sempre tem precedência menor que a versão normal com o mesmo major.minor.patch.

Como 1.0.0-alpha.1 se compara a 1.0.0-alpha.beta? Os identificadores são divididos por pontos e comparados da esquerda para a direita. Os numéricos comparam-se como números, os que têm letras ordenam-se em ordem ASCII, e um identificador apenas numérico sempre vale menos que um com letras.

Duas versões que só diferem nos metadados de build contam como diferentes? Não. 1.0.0+build.1 e 1.0.0+build.999 têm precedência igual (A = B). Os metadados de build são excluídos da comparação.

Posso colar v1.2.3 com o v inicial? Sim: um prefixo v, V ou = é removido antes da análise. A string resultante ainda precisa ser um SemVer 2.0.0 válido (MAJOR.MINOR.PATCH).

E uma string curta como 1.2 ou 1? O SemVer 2.0.0 exige os três números, então 1.2 é tratado como inválido. Complete para 1.2.0 e ele será analisado.

📚 Curiosidades sobre o algoritmo de precedência

O SemVer, publicado pelo cofundador do GitHub Tom Preston-Werner, dá um significado compartilhado aos números MAJOR.MINOR.PATCH: aumente MAJOR para mudanças que quebram compatibilidade, MINOR para recursos retrocompatíveis e PATCH para correções retrocompatíveis. Gerenciadores como npm e Cargo apoiam-se nessa semântica para resolver intervalos de dependências.

O ponto que mais gera erro é a ordenação das pre-releases. A especificação define um algoritmo preciso: quando todos os identificadores anteriores são iguais, o conjunto com mais campos de pre-release tem precedência maior, de modo que 1.0.0-alpha.1 é anterior a 1.0.0-alpha.1.1. Como essas regras são fáceis de esquecer, colocar duas versões lado a lado e ler a decomposição é uma verificação rápida antes de confiar num comparador escondido dentro de um script de CI.