AZ Tools

Herramientas Semver (Parser, Comparador, Incremento)

Desarrollo

Trabajar con npm, Cargo, módulos de Go o cualquier ecosistema de paquetes significa mirar cadenas de versiones semánticas — y equivocarse (tratar 1.10.0 como menor que 1.9.0, perderse una etiqueta prerelease) es el tipo de error que cuesta horas. Esta herramienta parsea dos versiones en sus componentes (major, minor, patch, prerelease, build), las compara según la especificación oficial de semver.org incluyendo orden correcto de prerelease, y ofrece botones de incremento de un clic. Debajo, el expansor de rango convierte la sintaxis npm más común (^1.2.3, ~1.2.3, ~1.2, ^0.x.y para APIs inestables) en los límites explícitos ≥inferior <superior — útil cuando una herramienta solo acepta esa forma.

Mayor1
Menor2
Parche3
Prerelease
Build
Mayor1
Menor2
Parche10
Prerelease
Build

Comparación

B es mayor que A

Coincide con

≥ 1.2.3·< 2.0.0

Cómo usar

  1. Escribe una versión en cada entrada (Versión A y B); los componentes parseados y la comparación se actualizan en vivo.
  2. Haz clic en un botón de incremento (Mayor / Menor / Parche / Prerelease) bajo cada versión para avanzarla — útil para planear un release.
  3. En el expansor de rango, escribe un rango como ^1.2.3 o ~1.2 — aparecen los límites; usa Copiar para obtener la cadena ≥a.b.c <x.y.z.

Preguntas frecuentes

¿Cómo funciona el orden de prerelease?
Por especificación, una versión con prerelease (1.0.0-alpha) es menor que la misma sin él (1.0.0). Dentro de los prereleases, los identificadores se comparan de izquierda a derecha: los numéricos numéricamente, los alfanuméricos léxicamente, y los numéricos siempre rankean menos que los alfanuméricos en la misma posición. Así que 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0.
¿Por qué ^0.2.3 se expande a <0.3.0, no <1.0.0?
El caret en npm trata 0.x.y de forma especial porque las APIs pre-1.0 son inestables: una bump en 0.x se trata como breaking. Así ^0.2.3 solo matchea 0.2.x, y ^0.0.3 solo matchea 0.0.3 exactamente. Es el mismo comportamiento que usa npm.
¿La metadata de build afecta comparaciones?
No — por especificación, +build es solo informativo y se ignora al comparar versiones. 1.0.0+abc y 1.0.0+xyz son iguales.
¿Qué sintaxis de rango se soporta aquí?
El expansor maneja ^x[.y[.z]], ~x[.y[.z]] y x o x.y solos (que se comportan como ~x y ~x.y respectivamente). Rangos combinados como '>=1.0.0 <2.0.0' o wildcards como '1.x' no se expanden — pero igual puedes parsear cada versión por separado.

Herramientas relacionadas