Qual è il significato del ~>
requisito della versione nelle specifiche delle gemme?
hanna-0.1.12 dipende da [haml (~> 2.2.8)]
Qual è il significato del ~>
requisito della versione nelle specifiche delle gemme?
hanna-0.1.12 dipende da [haml (~> 2.2.8)]
Risposte:
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
Le prime n-1 parti del numero di versione devono essere identiche alle prime n-1 parti del vincolo (ad es. 1.x
O 3.5.6.x
corrispondono, ma 0.x
o 3.5.7.x
no) e
L'ultima parte del numero di versione deve essere maggiore o uguale all'ultima parte del vincolo (ad es. 1.9999
E 3.5.6.2
corrisponde, 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
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 ).
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
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.
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.
~> 2.0
e ~> 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.
~> 2.2.8
sarà 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.