search

Found

info Descripción

Analiza dos cadenas de versión según SemVer 2.0.0 separando major, minor, patch, pre-release y build, y aplica el orden estricto de la especificación.

📘 Cómo usar

  1. Escribe la primera cadena de versión en el campo Versión A
  2. Escribe la segunda cadena de versión en el campo Versión B
  3. Revisa el símbolo del resultado y el desglose de major / minor / patch / pre-release / build

Comparador de Versiones SemVer

※ La comparación sigue las reglas de precedencia de SemVer 2.0.0 (https://semver.org/).

※ La metadata de build (tras +) se ignora al comparar la precedencia.

Resultado

Componentes de A

major
minor
patch
pre-release
build

Componentes de B

major
minor
patch
pre-release
build
Copiado
Article

Comparador de Versiones SemVer | Decide qué versión es más reciente según SemVer 2.0.0

Analiza dos cadenas de versión con la especificación SemVer 2.0.0, las separa en major / minor / patch / pre-release / build y devuelve un veredicto estricto de precedencia. Casos como 1.2.3 frente a 1.10.0-rc.1 se vuelven transparentes con un símbolo y el desglose de componentes.

💡 Sobre esta herramienta

Comparar versiones no es lo mismo que ordenar texto. Si comparas 1.9.0 y 1.10.0 como cadenas de caracteres, el 9 parece mayor que el 1, así que 1.9.0 ganaría, lo cual es incorrecto. SemVer compara el campo minor de forma numérica, por lo que 1.10.0 es la versión más reciente. Este detalle del «9 frente a 10» es justo lo que confunde al revisar el diff de un lockfile o al decidir si una actualización es segura.

Pega dos versiones y la herramienta analiza cada una, compara major / minor / patch como números enteros y luego aplica las reglas de precedencia de pre-release, devolviendo A < B, A = B o A > B. Cada versión se separa en sus componentes en una tarjeta vertical para que veas por qué sale ese veredicto. Los metadatos de build (todo lo que va después de +) se ignoran en la precedencia según la especificación, y el desglose lo muestra con claridad.

🧐 Preguntas Frecuentes

¿1.0.0-alpha es más antigua o más reciente que 1.0.0? 1.0.0 es más reciente. Una versión pre-release siempre tiene menor precedencia que la versión normal con el mismo major.minor.patch.

¿Cómo se compara 1.0.0-alpha.1 con 1.0.0-alpha.beta? Los identificadores se dividen por puntos y se comparan de izquierda a derecha. Los numéricos se comparan como números, los que tienen letras se ordenan en orden ASCII, y un identificador solo numérico siempre vale menos que uno con letras.

¿Dos versiones que solo difieren en los metadatos de build cuentan como distintas? No. 1.0.0+build.1 y 1.0.0+build.999 tienen igual precedencia (A = B). Los metadatos de build se excluyen de la comparación.

¿Puedo pegar v1.2.3 con la v inicial? Sí: se eliminan los prefijos v, V o = antes de analizar. La cadena resultante debe seguir siendo SemVer 2.0.0 válido (MAJOR.MINOR.PATCH).

¿Y una cadena corta como 1.2 o 1? SemVer 2.0.0 exige los tres números, así que 1.2 se considera inválido. Complétalo a 1.2.0 y se analizará.

📚 Cómo funciona la precedencia paso a paso

SemVer, publicado por el cofundador de GitHub Tom Preston-Werner, da un significado compartido a los números MAJOR.MINOR.PATCH: sube MAJOR ante cambios que rompen compatibilidad, MINOR ante funciones compatibles y PATCH ante correcciones compatibles. Gestores como npm y Cargo se apoyan en esta semántica para resolver rangos de dependencias.

Para aprender la lógica conviene seguir el algoritmo de la especificación: primero se comparan major, minor y patch como enteros; si son iguales, se entra en los identificadores de pre-release. Allí, cuando todos los campos previos coinciden, el conjunto con más campos tiene mayor precedencia, de modo que 1.0.0-alpha.1 es anterior a 1.0.0-alpha.1.1. Colocar dos versiones lado a lado y leer el desglose es una forma sencilla de interiorizar estas reglas sin tener que memorizarlas.