Calculadora de versiones semánticas
Calcula el siguiente número de versión, comprueba cuál de dos versiones es más nueva, mira exactamente qué permite un rango npm como ^1.2.0 o ~1.4 u ordena una lista desordenada de versiones, todo con las reglas oficiales de precedencia de SemVer 2.0.0.
Última actualización:
La usan los tipos de incremento pre*, como npm version --preid
Sintaxis npm: ^1.2.3, ~1.2, 1.x, >=1.0.0 <2.0.0, 1.0.0 - 1.5.0, unidos con ||
Cómo usar Calculadora de versiones semánticas
- Elige una tarea: incrementar, comparar, probar un rango u ordenar.
- Escribe tu(s) versión(es). Se acepta una v inicial (v1.2.3); los metadatos de compilación después de + se conservan pero se ignoran al ordenar.
- Para un incremento, elige el tipo de incremento y, para las pre-releases, una etiqueta como beta.
- Para un rango, pega el rango de package.json y las versiones que quieras probar.
- Lee el resultado y el desarrollo, luego cópialo o descarga la tabla en CSV.
La precedencia SemVer en cuatro reglas
- Compara MAJOR, MINOR y PATCH como números, de izquierda a derecha. La primera diferencia decide: 2.0.0 > 1.99.99 y 1.10.0 > 1.9.0.
- Una pre-release está por debajo de su versión final: 1.0.0-rc.1 < 1.0.0.
- Los identificadores de pre-release se comparan uno por uno: los números de forma numérica (beta.2 < beta.11), las palabras en orden ASCII (alpha < beta < rc), y un número siempre queda por debajo de una palabra.
- Gana la que tiene más identificadores cuando todos los anteriores son iguales: 1.0.0-alpha < 1.0.0-alpha.1. Los metadatos de compilación después de + nunca cuentan.
Orden de ejemplo completo: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
Guía rápida de rangos npm
| Rango | Significa | Permite, por ejemplo |
|---|---|---|
| ^1.2.3 | >=1.2.3 <2.0.0-0 | 1.2.3, 1.3.0, 1.99.0 |
| ^0.2.3 | >=0.2.3 <0.3.0-0 | 0.2.3, 0.2.9 (no 0.3.0) |
| ^0.0.3 | >=0.0.3 <0.0.4-0 | solo 0.0.3 |
| ~1.2.3 | >=1.2.3 <1.3.0-0 | 1.2.3, 1.2.10 |
| ~1 | >=1.0.0 <2.0.0-0 | de 1.0.0 a 1.x.x |
| 1.2.x o 1.2 | >=1.2.0 <1.3.0-0 | 1.2.0, 1.2.7 |
| 1.2.3 - 2.3 | >=1.2.3 <2.4.0-0 | de 1.2.3 hasta 2.3.x |
| >1.2 | >=1.3.0 | 1.3.0 y posteriores |
| <=1.2 | <1.3.0-0 | cualquiera hasta 1.2.x |
| * o "" o x | cualquier versión | todas las versiones estables |
| A || B | A o B | ^1.0.0 || ^2.0.0 |
¿Qué número debo incrementar?
| Cambio que hiciste | Incremento | 1.4.2 pasa a ser |
|---|---|---|
| Corregiste un error, sin cambios en la API | patch | 1.4.3 |
| Agregaste una función y el código anterior sigue funcionando | minor | 1.5.0 |
| Quitaste o cambiaste algo de lo que dependen los usuarios | major | 2.0.0 |
| Pruebas de la siguiente major antes del lanzamiento | premajor --preid=beta | 2.0.0-beta.0 |
| Otra compilación de prueba | prerelease | 2.0.0-beta.1 |
Las versiones 0.y.z son para el desarrollo inicial: cualquier cosa puede cambiar en cualquier momento, por eso el caret trata el primer número distinto de cero como el "major". Publica la 1.0.0 cuando tu API pública sea estable.
Preguntas frecuentes
¿Qué es el versionado semántico?
El versionado semántico (SemVer 2.0.0) escribe las versiones como MAJOR.MINOR.PATCH. Aumentas MAJOR para cambios incompatibles en la API, MINOR para funciones compatibles con versiones anteriores y PATCH para correcciones de errores compatibles. Pueden seguir partes opcionales de pre-release (-beta.1) y de compilación (+sha.5114f85).
¿Qué diferencia hay entre ^ y ~ en package.json?
El caret permite cambios que no modifiquen el primer número distinto de cero por la izquierda: ^1.2.3 significa >=1.2.3 <2.0.0, pero ^0.2.3 significa >=0.2.3 <0.3.0. La tilde solo permite actualizaciones de patch cuando se indica un minor: ~1.2.3 significa >=1.2.3 <1.3.0.
¿Por qué 1.10.0 es más nueva que 1.9.0?
Cada parte se compara como número entero, no como texto. 10 es mayor que 9, así que 1.10.0 tiene mayor precedencia aunque alfabéticamente iría antes.
¿1.0.0-rc.1 es mayor o menor que 1.0.0?
Menor. Una versión pre-release está por debajo de la versión normal con el mismo MAJOR.MINOR.PATCH, así que 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0.
¿Por qué ^1.2.0 no coincide con 1.5.0-beta.1?
npm omite las pre-releases salvo que un comparador de la misma parte del rango también tenga una pre-release en el mismo MAJOR.MINOR.PATCH. Así se evita que los usuarios reciban compilaciones inestables por accidente. Marca 'Incluir pre-releases' para que coincidan de todos modos, como la opción --include-prerelease.
¿Qué significa el -0 en <2.0.0-0?
Es la pre-release más baja posible de 2.0.0. Escribir el límite superior como <2.0.0-0 excluye todas las pre-releases de 2.0.0 y también la propia 2.0.0, que es como npm expande ^1.2.3 internamente.
¿Los metadatos de compilación afectan el orden de las versiones?
No. Todo lo que va después de un signo más, como +build.42, se ignora al determinar la precedencia, así que 1.0.0+a y 1.0.0+b tienen el mismo rango.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.