2010-08-05 4 views
72

Qual è il significato del requisito di versione ~> nelle specifiche della gemma?Significato della tilde-maggiore di (~>) nei requisiti di versione?

 
hanna-0.1.12 depends on [haml (~> 2.2.8)] 
+23

A volte viene chiamato operatore spermatico. –

+3

o [twiddle-wakka] (http://guides.rubygems.org/patterns/#pessimistic_version_constraint) – SuckerForMayhem

+3

+1 @SuckerForMayhem, "twiddle-wakka" è più divertente. Nuovo link: http://guides.rubygems.org/patterns/#pessimistic-version-constraint - che a sua volta si collega a https://robots.thoughtbot.com/rubys-pessimistic-operator –

risposta

76

Il manuale RubyGems lo chiama pessimistic version constraint.

Si supponga di aver specificato un numero di versione n-part, ad es. 1.3 (2 parti) o 3.5.6.2 (4 parti) come vincolo. Quindi, al fine di soddisfare il vincolo, un numero di versione deve soddisfare entrambe le seguenti condizioni

  1. Il primo n-1 parti del numero di versione deve essere identico al primo n-1 parti del vincolo (es 1.x o 3.5.6.x partita, ma 0.x o 3.5.7.x non) e

  2. l'ultima parte del numero di versione deve essere maggiore o uguale all'ultimo parte del vincolo (ad es. 1.9999 e 3.5.6.2 corrispondenza, ma 1.2 o 3.5.6.1 no).

In altre parole

 
~> x_1.x_2.x_3. … .x_n-2.x_n-1.x_n 

corrisponde

 
x_1.x_2.x_3. … .x_n-2.x_n-1.y, y = x_n 

La ragione per questo è chiamato un vincolo "pessimista", e anche il caso d'uso per esso, è che quando basta dite > x.y.z, siete ottimisti: date per scontato che da qui in avanti, fino all'eternità, l'API non cambierà mai. Questo è ovviamente un assunto piuttosto audace. Tuttavia, la maggior parte dei progetti hanno regole su quando essi sono autorizzati a break backwards compatibility, e come devono cambiare il loro numero di versione quando fanno pausa all'indietro compatibilità. Puoi codificare le regole di numerazione delle versioni utilizzando un vincolo pessimistico , e quindi puoi essere certo che il tuo codice continuerà a funzionare sempre (supponendo che l'autore dell'altro progetto aderisca effettivamente alle sue regole , che sfortunatamente non è sempre il caso).

+20

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

-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 un'API che interrompe il cambiamento in una nuova gemma, non dipenda da quella gemma appena cambiata che in questo caso si romperebbe hanna.

+7

Questo non è corretto, ma è incompleto. È importante sottolineare la differenza tra '~> 2.0' e' ~> 2.0.0' - il primo 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. –

+5

@James A. Rosen: Inoltre, '~> 2.2.8' non * corrisponde * a qualsiasi versione 2.2.x" come afferma la risposta, ma solo versioni 2.2.x con x ≥ 8. IOW: la risposta è a meglio ancora più incompleto, confinante con errori e sicuramente fuorvianti. –

10

In altre parole, è possibile utilizzare questo simbolo per mantenere aggiornato il tuo gioiello con tutti gli aggiornamenti minori ed evitare di effettuare un aggiornamento importante in grado di interrompere l'app.

Ad esempio "~> 1.2" aggiornerà il tuo gem a 1.3 (se tale versione è rilasciata) ma non lo aggiornerà a 2.0

7

Penso bundler docs meglio riassumere questo:

L'identificatore ~> ha un significato speciale, meglio mostrato con l'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.