Significato di tilde-maggiore-di (~>) nei requisiti di versione?


92

Qual è il significato del ~>requisito della versione nelle specifiche delle gemme?

hanna-0.1.12 dipende da [haml (~> 2.2.8)]

27
A volte è chiamato operatore spermatico.
Andrew Grimm


3
+1 @SuckerForMayhem, "twiddle-wakka" è più divertente. Nuovo collegamento: guides.rubygems.org/patterns/#pessimistic-version-constraint - che si collega a robots.thoughtbot.com/rubys-pessimistic-operator
The Red Pea

2
@SuckerForMayhem Twiddle-wakka suona come una specie di bestia leggendaria come il chupacabra. Questo è stato il mio contributo all'argomento. Sei la benvenuta società.
twiz

1
grazie per i link aggiornati @TheRedPea
SuckerForMayhem

Risposte:


93

Il manuale di RubyGems definisce questo un vincolo di versione pessimistico .

Supponiamo di aver specificato un numero di versione in n parti, ad esempio 1.3(2 parti) o 3.5.6.2(4 parti) come vincolo. Quindi, per soddisfare il vincolo, un numero di versione deve soddisfare entrambe le seguenti condizioni

  1. Le prime n-1 parti del numero di versione devono essere identiche alle prime n-1 parti del vincolo (ad es. 1.xO 3.5.6.xcorrispondono, ma 0.xo 3.5.7.xno) e

  2. L'ultima parte del numero di versione deve essere maggiore o uguale all'ultima parte del vincolo (ad es. 1.9999E 3.5.6.2corrisponde, ma 1.2o 3.5.6.1no).

In altre parole

~> X 1 .x 2 .x 3 . … .X n-2 .x n-1 .x n

partite

x 1 .x 2 .x 3 . … .X n-2 .x n-1 .y, y> = x n

Il motivo per cui questo è chiamato un vincolo "pessimistico", e anche il suo caso d'uso, è che quando dici semplicemente > x.y.z, sei ottimista: presumi che da qui in avanti, fino all'eternità, l'API non cambierà mai. Questo è ovviamente un presupposto piuttosto audace. Tuttavia, la maggior parte dei progetti hanno regole su quando essi sono autorizzati a rompere la compatibilità a ritroso , e come devono cambiare il loro numero di versione, quando fanno la compatibilità all'indietro rottura. Puoi codificare quelle regole di numerazione delle versioni usando un vincolo pessimistico, e così puoi essere sicuro che il tuo codice continuerà sempre a funzionare (supponendo che l'autore dell'altro progetto aderisca effettivamente alle sue regole, che purtroppo non è sempre il caso ).


32
In altre parole: ~> significa che consentirà solo quella versione specifica e le versioni secondarie più recenti nell'ultimo decimale.
Magne

18

In altre parole, puoi usare questo simbolo per mantenere la tua gemma aggiornata con tutti gli aggiornamenti minori ed evitare di fare un aggiornamento importante che può danneggiare la tua app.

Ad esempio "~> 1.2" aggiornerà la tua gemma alla 1.3 (se viene rilasciata una tale versione) ma non la aggiornerà alla 2.0


13

Penso che i documenti del bundler riassumano meglio questo:

Lo specificatore ~> ha un significato speciale, meglio mostrato dall'esempio. ~> 2.0.3 è identico a> = 2.0.3 e <2.1. ~> 2.1 è identico a> = 2.1 e <3.0. ~> 2.2.beta corrisponderà alle versioni prerelease come 2.2.beta.12.


1
Temo di no. Sono felice che la risposta accettata lo spieghi in modo più dettagliato. Questa spiegazione basata su esempi non mi aiuta davvero a capire cosa intende l'operatore.
tripleee

-1

Corrisponde a qualsiasi versione che abbia la stessa parte maggiore / minore. Ciò significa che in questo caso haml ~> 2.2.8 corrisponderà a qualsiasi versione 2.2.x.

Questo può essere usato per assicurarsi che una modifica API in una nuova gemma non risulti dipendente da quella gemma appena cambiata che in questo caso romperebbe hanna.


7
Questo non è corretto, ma è incompleto. È importante sottostimare la differenza tra ~> 2.0e ~> 2.0.0- la prima corrisponde a 2.0, 2.1, 2.2.7 e tutto il resto fino a (ma non incluso) 3.0. Quest'ultimo corrisponde a 2.0, 2.0.1, 2.0.999 e tutto il resto fino a (ma non incluso) 2.1.
James A. Rosen

5
@James A. Rosen: Inoltre, ~> 2.2.8sarà non corrisponde a "qualsiasi 2.2.x" versione come afferma la risposta, ma solo 2.2.x versioni con x ≥ 8. IOW: la risposta è nella migliore delle ipotesi ancora più incompleta, confinante con errata e sicuramente ingannevole.
Jörg W Mittag
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.