¿Cuál es la diferencia entre tilde (~) y caret (^) en package.json?


3388

Después de actualizar a la última versión estable nodee npmintenténpm install moment --save . Guarda la entrada en el package.jsoncon el ^prefijo caret . Anteriormente, era un ~prefijo tilde .

  1. ¿Por qué se realizan estos cambios npm?
  2. ¿Cuál es la diferencia entre tilde? ~ y caret ^?
  3. ¿Cuáles son las ventajas sobre los demás?

42
FYI puede evitar que los prefijos o utilizar una costumbre haciendo: npm config set save-prefix=''. (Pegue ~las comillas si eso es lo que prefiere). Yo personalmente hago esto y reduzco las cosas en producción.
fncomp

19
Todos los detalles esenciales de cómo funcionan tilde y caret y las diferencias: github.com/npm/node-semver#tilde-ranges-123-12-1
Jeffrey Martinez

11
Esta herramienta es una gran ayuda para probar semver.npmjs.com
chaiyachaiya

@fncomp solo quería aclarar si recibí tu comentario correctamente ... ¿utilizas solo versiones específicas de dependencias en tu proyecto? nuestro equipo duda en actualizar las dependencias ... ¿recomendaría usar versiones específicas o el prefijo '~' para las dependencias?
blogs4t

@fncomp, ¿podría detallar lo que quiere decir al decir "Yo personalmente hago esto y encojo para las cosas en producción". ¡Gracias!
blogs4t

Respuestas:


3849

Vea los documentos NPM y los documentos semver :

  • ~ versión "Aproximadamente equivalente a la versión", lo actualizará a todas las futuras versiones de parche, sin incrementar la versión menor. ~1.2.3utilizará versiones de 1.2.3 a <1.3.0.

  • ^ versión "Compatible con la versión", lo actualizará a todas las futuras versiones menores / parches, sin incrementar la versión principal. ^2.3.4utilizará versiones de 2.3.4 a <3.0.0.

Consulte los comentarios a continuación para ver las excepciones, en particular para las versiones anteriores, como ^ 0.2.3


325
Publicar aquí para capturar a personas que no piensan bien esto, pero tanto ^ como ~ asumen que puedes confiar en lanzamientos menores y puntuales de tus dependencias. Si está publicando una biblioteca y desea que otras personas confíen en usted, NO ACEPTE A CIERTAS DEPENDENCIAS DE ABAJO. Una mala liberación de puntos de su dependencia puede causar una reacción en cadena aguas arriba, y hará que la gente toque a SU puerta cuando las cosas se pongan en forma de pera. Esta es otra gran razón para usar npm shrinkwrap en su código de producción.
tehfoo

8
También puede eliminar todas las tonterías de npm anteponiendo sus versiones con a ^o a ~. Establezca esto si desea tener un control estricto sobre sus versiones: npm config set save-prefix=''
kumarharsh

55
@prasanthv tiene razón: de docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 : Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0 .4. Permite cambios que no modifican el dígito más a la izquierda que no es cero en la tupla [mayor, menor, parche]. En otras palabras, esto permite parches y actualizaciones menores para las versiones 1.0.0 y superiores, parches para las versiones 0.X> = 0.1.0, y no hay actualizaciones para las versiones 0.0.X.
rofrol

16
@jgillich en semver cuando lo usas 0.2.x, 2no es un major version. Es por eso que docs.npmjs.com utilizan las palabras específicas: the left-most non-zero digit. También qué pasa con este caso: ^ 0.0.4 significa 0.0.4
rofrol

11
@FagnerBrack: El ejemplo específico que proporcionó es correcto, pero generalmente su forma de pensar es incorrecta. Un ejemplo: vamos a decir que tienes el paquete Aen 3 versiones: 0.0.1, 0.0.2y 0.0.3. Hay un error, por 0.0.1lo que desea tener al menos 0.0.2en su paquete B. Si escribes 0.0.xobtendrás 0.0.3, lo cual está bien. Pero si algún otro paquete Crequiere ambos By Aademás tiene restricciones "A": "<0.0.2", obtendrá 0.0.1sin mostrar ningún problema de conflicto, que no es lo que desea. Usar tilde ~0.0.2debería ayudarlo a evitar este problema.
Maciej Sz

863

Me gustaría agregar también la documentación oficial de npmjs que describe todos los métodos para la especificidad de la versión, incluidos los mencionados en la pregunta:

https://docs.npmjs.com/files/package.json

https://docs.npmjs.com/misc/semver#x-ranges-12x-1x-12-

  • ~version"Aproximadamente equivalente a la versión" Ver npm semver - Tilde Ranges & semver (7)
  • ^version"Compatible con la versión" Ver npm semver - Caret Ranges & semver (7)
  • version Debe coincidir exactamente con la versión
  • >version Debe ser mayor que la versión
  • >=version etc.
  • <version
  • <=version
  • 1.2.x 1.2.0, 1.2.1, etc., pero no 1.3.0
  • http://sometarballurl (esta puede ser la URL de un tarball que se descargará e instalará localmente
  • * Coincide con cualquier versión
  • latest Obtiene la última versión

La lista de arriba no es exhaustiva. Otros especificadores de versión incluyen URL de GitHub y repositorios de usuario de GitHub, rutas locales y paquetes con etiquetas npm específicas


8
También es posible especificar un rango exacto de versiones, como 1.2.0 || >=1.2.2 <1.3.0: Exactamente 1.2.0, o todo, desde 1.2.2 a 1.3.0 (inclusive), pero no 1.2.1, o 1.3.1 y superior, y tampoco 1.1 .x y abajo.
CodeManX

Un enlace más específico desde arriba -> docs.npmjs.com/files/package.json#dependencies
Toby

"Approximately equivalent to version"y "Compatible with version"son formas frustrantemente inespecíficas de describir el comportamiento ~ y ^. ¡Gracias @jgillich por proporcionar una respuesta real!
Scott Stafford

636

npm permite instalar una versión más nueva de un paquete que la especificada. El uso de tilde ( ~) le brinda versiones de corrección de errores y caret ( ^) también le brinda una nueva funcionalidad compatible con versiones anteriores.

El problema es que las versiones antiguas generalmente no reciben muchas correcciones de errores, por lo que npm usa caret ( ^) como predeterminado --save.

mesa semver

Según: "Semver explicó: ¿por qué hay un símbolo de intercalación (^) en mi paquete.json?" .

Tenga en cuenta que las reglas se aplican a las versiones anteriores a 1.0.0 y no todos los proyectos siguen versiones semánticas. Para las versiones 0.xx, el cursor solo permite actualizaciones de parches , es decir, se comporta igual que la tilde. Ver "Gamas de Caret"

Aquí hay una explicación visual de los conceptos:

diagrama de semver

Fuente: "Hoja de referencia de versiones semánticas" .


2
¿Qué pasa con ^ 0.2.5? de docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4 : Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Permite cambios que no modifican el dígito más a la izquierda que no es cero en la tupla [mayor, menor, parche]. En otras palabras, esto permite parches y actualizaciones menores para las versiones 1.0.0 y superiores, parches para las versiones 0.X> = 0.1.0, y no hay actualizaciones para las versiones 0.0.X.
rofrol

11
@rofrol cualquier versión anterior a 1.0.0 se considera inestable y estas reglas no se aplican
pspi

2
Entonces su explicación no está completa
rofrol

55
@rofrol sí, omitir la legibilidad es bueno a veces, las posibilidades de tener algo por debajo de 1.0.0 para una dependencia en el paquete json son bastante bajas. ver también el principio 20/80, es una gran regla para enfocarse en lo que importa
pspi

1
@pspi Tener versiones inferiores a 1.0.0 es "poco probable"? De 60 tenemos ~ 15, y la mayoría de ellos no son oscuros.
Dave Newton el

99

Semver

<major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2
  • Use la calculadora npm semver para la prueba. (Aunque las explicaciones para ^ (incluye todo lo que es mayor que una versión particular en el mismo rango mayor) y ~ (incluye todo lo que es mayor que una versión particular en el mismo rango menor) no son 100% correctas, la calculadora parece funcionar bien )
  • Alternativamente, use SemVer Check en su lugar, que no requiere que elija un paquete y también ofrece explicaciones.

Permitir o rechazar cambios

  • Pin versión: 1.2.3.
  • Uso ^(como la cabeza). Permite actualizaciones en el segundo nivel distinto de cero desde la izquierda: ^0.2.3significa 0.2.3 <= v < 0.3.
  • Uso ~(como la cola). Generalmente congela el nivel más a la derecha o establece cero si se omite:
    • ~1 medio 1.0.0 <= v < 2.0.0
    • ~1.2significa 1.2.0 <= v < 1.3.0.
    • ~1.2.4significa 1.2.4 <= v < 1.3.0.
  • Omitir el nivel más a la derecha: 0.2medios 0.2 <= v < 1. Difiere de ~porque:
    • Iniciar la versión de nivel omitida siempre es 0
    • Puede establecer la versión principal inicial sin especificar subniveles.

Todas (con suerte) posibilidades

Establezca el inicio a nivel principal y permita actualizaciones hacia arriba

*  or "(empty string)   any version
1                         v >= 1

Congelar a nivel mayor

~0 (0)            0.0 <= v < 1
0.2               0.2 <= v < 1          // Can't do that with ^ or ~ 
~1 (1, ^1)        1 <= v < 2
^1.2              1.2 <= v < 2
^1.2.3            1.2.3 <= v < 2
^1.2.3-beta.4     1.2.3-beta.4 <= v < 2

Congelar a nivel menor

^0.0 (0.0)        0 <= v < 0.1
~0.2              0.2 <= v < 0.3
~1.2              1.2 <= v < 1.3
~0.2.3 (^0.2.3)   0.2.3 <= v < 0.3
~1.2.3            1.2.3 <= v < 1.3

Nivel de parche congelado

~1.2.3-beta.4     1.2.3-beta.4 <= v < 1.2.4 (only beta or pr allowed)
^0.0.3-beta       0.0.3-beta.0 <= v < 0.0.4 or 0.0.3-pr.0 <= v < 0.0.4 (only beta or pr allowed)
^0.0.3-beta.4     0.0.3-beta.4 <= v < 0.0.4 or 0.0.3-pr.4 <= v < 0.0.4 (only beta or pr allowed)

No permitir actualizaciones

1.2.3             1.2.3
^0.0.3 (0.0.3)    0.0.3

Aviso : Falta mayor, menor, parche o especificación betasin número, es lo mismo que anypara el nivel faltante.

Aviso : cuando instala un paquete que tiene 0un nivel principal, la actualización solo instalará una nueva versión de nivel beta / pr. Esto se debe a que se npmestablece ^como predeterminado en package.jsony cuando la versión instalada es similar 0.1.3, congela todos los niveles principales / menores / parches.


Decirle a la gente que evite iniciar proyectos desde 0 porque la biblioteca y los desarrolladores consumidores no entienden que el sistema es una solución terrible. Creo que @asdfasdfads tiene mucha mejor información.
ProLoser

@ProLoser Creo que el sistema debería simplificarse y no deberíamos usar versiones 0.x.
rofrol

1
El caso de uso sobre el desarrollo temprano del ciclo de vida y v0 tiene MUCHO sentido. Aprender cómo se comporta correctamente v0 realmente me ha hecho esperar otros proyectos de ciclo de vida temprano. Significa que puede tener una API que cambia rápidamente con mucha incompatibilidad con versiones anteriores sin verse obligado a declarar su proyecto como 1.x (también conocido como: estable) cuando realmente no lo es.
ProLoser

Lo entiendo, pero simplemente no me gusta cómo funciona con semver y calificadores
rofrol

2
Se siente más como una opinión y no debe enmarcarse como un enfoque generalmente aceptado. Y ^ 0.1.x obtiene parches perfectamente bien.
ProLoser

93

~corrige números mayores y menores. Se usa cuando está listo para aceptar correcciones de errores en su dependencia, pero no desea ningún cambio potencialmente incompatible.

^solo arregla el número mayor. Se usa cuando observa de cerca sus dependencias y está listo para cambiar rápidamente su código si una versión menor es incompatible.

Además de eso, ^es no compatible con las versiones antiguas de npm y debe usarse con precaución.

Entonces, ^es un buen defecto, pero no es perfecto. Sugiero elegir cuidadosamente y configurar el operador de semver que sea más útil para usted.


13
no es cierto: Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Permite cambios que no modifican el dígito más a la izquierda que no es cero en la tupla [mayor, menor, parche]. En otras palabras, esto permite parches y actualizaciones menores para las versiones 1.0.0 y superiores, parches para las versiones 0.X> = 0.1.0, y no hay actualizaciones para las versiones 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4
rofrol

66
Esta respuesta es completamente incorrecta (como muchas otras aquí). ¡Ninguno de estos arregla un número mayor! Como dijo @rofrol, ^ simplemente mantiene el dígito más distinto de cero a la izquierda sin cambios. ~ por otro lado, solo permite actualizaciones de parches si se especifica la versión menor (por ejemplo, ~ 1.2.3 o ~ 1.2) y permite actualizaciones menores si no se especifica la versión menor (por ejemplo, ~ 1).
TheBaj

2
@TheBaj Significan "arreglar" como "definir" ("fijar") en lugar de "ajustar", por lo que todos están de acuerdo en cómo se maneja el número principal.
maaartinus

1
Sí, esta respuesta parecía totalmente al revés hasta que me di cuenta de que el contestador quería decir "arreglar" como en "hacer fijo, estacionario o inmutable".
NattyC

57

~: Razonablemente cerca de

   ~1.1.5: 1.1.0 <= accepted < 1.2.0

^: Compatible con

   ^1.1.5: 1.1.5 <= accepted < 2.0.0

   ^0.1.3: 0.1.3 <= accepted < 0.2.0

   ^0.0.4: 0.0.4 <= accepted < 0.1.0

17
@kytwb - no. En el caso especial de los números de versión de liberación cero, el quilate es equivalente a la tilde. Por lo tanto, ^0.1.3solo acepta versiones 0.1.xy no aceptará 0.2.0, aunque sea un incremento menor. Este comportamiento es equivalente a ~0.1.3. El razonamiento detrás de este comportamiento se debe al hecho de que los paquetes de liberación zeroth todavía se consideran inestables; en palabras de semver.org , # 4, "cualquier cosa puede cambiar en cualquier momento" (incluidos los cambios incompatibles con versiones anteriores).
chharvey

31

^es 1. [cualquiera]. [cualquiera] (última versión menor)
~es 1.2. [cualquiera] (último parche)

Una buena lectura es esta publicación de blog sobre cómo se aplica semver a npm
y qué están haciendo para que coincida con el estándar de semver
http://blog.npmjs.org/post/98131109725/npm-2-0-0


2
no es cierto: Caret Ranges ^ 1.2.3 ^ 0.2.5 ^ 0.0.4. Permite cambios que no modifican el dígito más a la izquierda que no es cero en la tupla [mayor, menor, parche]. En otras palabras, esto permite parches y actualizaciones menores para las versiones 1.0.0 y superiores, parches para las versiones 0.X> = 0.1.0, y no hay actualizaciones para las versiones 0.0.X. docs.npmjs.com/misc/semver#caret-ranges-1-2-3-0-2-5-0-0-4
rofrol

28

La coincidencia de sombreros puede considerarse "rota" porque no se actualizará ^0.1.2a 0.2.0. Cuando el software está surgiendo, use 0.x.yversiones y la coincidencia de sombreros solo coincidirá con el último dígito variable ( y). Esto se hace a propósito. La razón es que mientras el software evoluciona, la API cambia rápidamente: un día tienes estos métodos y el otro día tienes esos métodos y los viejos se han ido. Si no desea descifrar el código para las personas que ya están utilizando su biblioteca, vaya e incremente la versión principal: por ejemplo, 1.0.0-> 2.0.0-> 3.0.0. Entonces, para cuando su software finalmente esté 100% listo y con todas las funciones, será como una versión 11.0.0y eso no parece muy significativo, y en realidad parece confuso. Si, por otro lado, estuvieras usando ->0.1.x->0.2.x0.3.x versiones de la , y cuando el software esté finalmente 100% listo y con todas las funciones, se lanzará como versión1.0.0 lance y significa "Esta versión es de servicio a largo plazo, puede continuar y usar esta versión de la biblioteca en su código de producción, y el autor no cambiará todo mañana, o el próximo mes, y no abandonará el paquete ".

La regla es: use el 0.x.ycontrol de versiones cuando su software aún no haya madurado y suéltelo incrementando el dígito del medio cuando cambie su API pública (por lo tanto, las personas que ^0.1.0no tengan 0.2.0actualización no romperán su código). Luego, cuando el software madure, suéltelo 1.0.0e incremente el dígito más a la izquierda cada vez que cambie su API pública (por lo tanto, las personas que ^1.0.0no obtengan 2.0.0actualizaciones y no romperán su código)

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Este comentario fue ridículamente útil y no parece estar documentado muy bien. ¿Tiene un enlace a la documentación sobre este comportamiento? Esta respuesta sobre los proyectos v0 me ha ayudado mucho.
ProLoser

No tengo un enlace: también encontré esta información buscando en Google y jugando con npm calculadora de versión semántica semver.npmjs.com
catamphetamine

2
Debe agregarse a su documentación de una manera más formal. Di una charla en Sony a mi equipo de ingeniería porque parece que se pasa por alto fácilmente. slides.com/proloser/semver-v0
ProLoser

24

~ Tilde:

  • ~congela números mayores y menores.
  • Se usa cuando está listo para aceptar correcciones de errores en su dependencia, pero no desea ningún cambio potencialmente incompatible.
  • La tilde coincide con la versión menor más reciente (el número del medio).
  • ~ 1.2.3 coincidirá con todas las versiones 1.2.x, pero perderá 1.3.0.
  • Tilde (~) te ofrece versiones de corrección de errores

^ Caret:

  • ^ congela solo el número principal.
  • Se usa cuando observa de cerca sus dependencias y está listo para cambiar rápidamente su código si una versión menor es incompatible.
  • Le actualizará a la versión principal más reciente (el primer número).
  • ^ 1.2.3 coincidirá con cualquier versión 1.xx incluyendo 1.3.0, pero se mantendrá en 2.0.0.
  • Caret (^) también te brinda una nueva funcionalidad compatible con versiones anteriores.

1
La tilde coincide con la versión de parche más reciente (el último número). El símbolo de intercalación coincide con la versión menor más reciente (el número del medio).
Abdul Rauf

"congela" es la mejor explicación.
mhrabiee

¿Caret congela el número principal y lo actualizará a la versión principal más reciente (el primer número)? El número principal es el primer número, por lo que esto no tiene sentido.
NattyC

19

Tilde ~ coincide con una versión menor, si ha instalado un paquete que tiene 1.4.2 y después de su instalación, las versiones 1.4.3 y 1.4.4 también están disponibles si en su package.json se usa como ~ 1.4.2 y luego npm install en su proyecto después de la actualización se instalará 1.4.4 en su proyecto. Pero hay 1.5.0 disponible para ese paquete, entonces no lo instalará ~. Se llama versión menor.

Caret ^ coincide con la versión principal, si el paquete 1.4.2 está instalado en su proyecto y después de que se lanza su instalación 1.5.0, entonces ^ instalará la versión principal. No permitirá instalar 2.1.0 si tiene ^ 1.4.2 .

Versión fija si no desea cambiar la versión del paquete en cada instalación, luego use la versión fija sin ningún carácter especial, por ejemplo, "1.4.2"

Última versión * Si desea instalar la última versión, utilice solo * delante del nombre del paquete.


3
Esta respuesta es engañosa. SemVer dice claramente: Un número de versión normal DEBE tomar la forma XYZ [donde] X es la versión principal, Y es la versión secundaria y Z es la versión del parche.
Leo

15

Una explicación de línea

El sistema de versiones estándar es major.minor.build (por ejemplo, 2.4.1)

npm verifica y corrige la versión de un paquete en particular basado en estos caracteres

~ : la versión principal es fija, la versión secundaria es fija, coincide con cualquier número de compilación

por ejemplo: ~ 2.4.1 significa que verificará 2.4.x donde x es cualquier cosa

^ : la versión principal es fija, coincide con cualquier versión menor, coincide con cualquier número de compilación

por ejemplo: ^ 2.4.1 significa que verificará 2.xx donde x es cualquier cosa


55
Veo 7 líneas en esta respuesta
FluxLemur

11

Probablemente haya visto tilde (~) y caret (^) en el paquete.json. ¿Cuál es la diferencia entre ellos?

Cuando haces npm install moment --save, guarda la entrada en package.json con el prefijo caret (^).

La tilde (~)

En los términos más simples, la tilde (~) coincide con la versión menor más reciente (el número del medio). ~ 1.2.3 coincidirá con todas las versiones 1.2.x pero perderá 1.3.0.

El caret (^)

El caret (^), por otro lado, está más relajado. Le actualizará a la versión principal más reciente (el primer número). ^ 1.2.3 coincidirá con cualquier versión 1.xx incluyendo 1.3.0, pero se retrasará en 2.0.0.

Referencia: https://medium.com/@Hardy2151/caret-and-tilde-in-package-json-57f1cbbe347b


Nuevamente, esta respuesta es engañosa. SemVer dice claramente: Un número de versión normal DEBE tomar la forma XYZ [donde] X es la versión principal, Y es la versión secundaria y Z es la versión del parche.
Leo

5

semver está separado en 3 secciones principales que se divide por puntos.

major.minor.patch
1.0.0

Estos diferentes principales, menores y parches se utilizan para identificar diferentes versiones. tide (~) y caret (^) se utilizan para identificar qué versión menor y parche se utilizará en el control de versiones de paquetes.

~1.0.1
 Install 1.0.1 or **latest patch versions** such as 1.0.2 ,1.0.5
^1.0.1
 Install 1.0.1 or **latest patch and minor versions** such as 1.0.2 ,1.1.0 ,1.1.1

4

Tilde (~)

la versión principal es fija, la versión secundaria es fija, coincide con cualquier número de compilación

"express": "~4.13.3" 

~4.13.3 significa que verificará 4.13.x donde x es cualquier cosa y 4.14.0

Caret (^)

la versión principal es fija, coincide con cualquier versión menor, coincide con cualquier número de compilación

"supertest": "^3.0.0"

^3.0.0 significa que verificará 3.xx donde x es cualquier cosa


¿Puede explicar cómo esta respuesta es diferente de la misma respuesta publicada hace 4 años ?
Franklin Yu

2

El número de versión está en sintaxis que designa cada sección con un significado diferente. La sintaxis se divide en tres secciones separadas por un punto.

major.minor.patch 1.0.2

Major, minor y patch representan las diferentes versiones de un paquete.

npm usa tilde (~) y caret (^) para designar qué parche y versiones menores usar respectivamente.

Entonces, si ve ~ 1.0.2, significa instalar la versión 1.0.2 o la última versión del parche, como 1.0.4. Si ve ^ 1.0.2 significa instalar la versión 1.0.2 o la última versión menor o parche como 1.1.0.


1
¿Puede explicar cómo esta respuesta es diferente de la misma respuesta publicada hace 4 años ?
Franklin Yu

2

quilates ^ incluyen todo lo que es mayor que una versión particular en el mismo rango principal.

tilde ~ incluye todo lo que es mayor que una versión particular en el mismo rango menor.

Por ejemplo, para especificar rangos de versiones aceptables hasta 1.0.4, use la siguiente sintaxis:

  • Lanzamientos de parches: 1.0 o 1.0.xo ~ 1.0.4
  • Lanzamientos menores: 1 o 1.xo ^ 1.0.4
  • Lanzamientos principales: * o x

Para obtener más información sobre la sintaxis de versiones semánticas, consulte la calculadora sempm de npm .

npm versiones semánticas en paquetes publicados§

Más de la documentación de npm Acerca del control de versiones semántico


1

No es una respuesta, per se, sino una observación que parece haberse pasado por alto.

La descripción de los rangos de quilates:

ver: https://github.com/npm/node-semver#caret-ranges-123-025-004

Permite cambios que no modifican el dígito más a la izquierda que no es cero en la tupla [mayor, menor, parche].

Significa que ^10.2.3 coinciden10.2.3 <= v < 20.0.0

No creo que eso sea lo que querían decir. Al introducir las versiones 11.xx a 19.xx, se romperá el código.

Creo que querían decir left most non-zero number field. No hay nada en SemVer que requiera que los campos numéricos sean de un solo dígito.


0

~ especificaciones para lanzamientos de versiones menores ^ especifica para lanzamientos de versiones principales

Por ejemplo, si la versión del paquete es 4.5.2, en la Actualización ~ 4.5.2 se instalará la última versión 4.5.x (VERSIÓN MENOR) ^ 4.5.2 instalará la última versión 4.xx (VERSIÓN MAYOR)


8
¿Puede explicar cómo esta respuesta es diferente de la misma respuesta publicada hace 4 años ?
Franklin Yu

0

En relación con esta pregunta, puede revisar la documentación de Composer sobre versiones , pero aquí en resumen:

  • Tilde Version Range ( ~ ) - ~ 1.2.3 es equivalente a> = 1.2.3 < 1.3.0
  • Rango de versión de Caret ( ^ ) - ~ 1.2.3 es equivalente a> = 1.2.3 < 2.0.0

Por lo tanto, con Tilde obtendrá actualizaciones automáticas de parches, pero las versiones menores y mayores no se actualizarán. Sin embargo, si usas Caret obtendrá parches y versiones menores, pero no obtendrá versiones principales (cambios importantes).

La versión Tilde se considera un enfoque "más seguro", pero si está utilizando dependencias confiables (bibliotecas bien mantenidas) no debería tener ningún problema con la versión Caret (porque los cambios menores no deberían ser cambios importantes.

Probablemente debería revisar esta publicación de stackoverflow sobre las diferencias entre la instalación y la actualización del compositor .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.