Quelle est la signification de l' ~>
exigence de version dans les spécifications des gemmes?
hanna-0.1.12 dépend de [haml (~> 2.2.8)]
Quelle est la signification de l' ~>
exigence de version dans les spécifications des gemmes?
hanna-0.1.12 dépend de [haml (~> 2.2.8)]
Réponses:
Le manuel RubyGems appelle cela une contrainte de version pessimiste .
Supposons que vous ayez spécifié un numéro de version en n parties, par exemple 1.3
(2 parties) ou
3.5.6.2
(4 parties) comme contrainte. Ensuite, pour remplir la contrainte, un numéro de version doit satisfaire les deux conditions suivantes
Les n-1 premières parties du numéro de version doivent être identiques aux n-1 premières parties de la contrainte (par exemple 1.x
ou 3.5.6.x
correspondre, mais 0.x
ou 3.5.7.x
non) et
La dernière partie du numéro de version doit être supérieure ou égale à la dernière partie de la contrainte (par exemple 1.9999
et 3.5.6.2
correspondre, mais 1.2
ou 3.5.6.1
non).
En d'autres termes
~> x 1 .x 2 .x 3 . … .X n-2 .x n-1 .x n
allumettes
x 1 .x 2 .x 3 . … .X n-2 .x n-1 .y, y> = x n
La raison pour laquelle on appelle cela une contrainte «pessimiste», et aussi son cas d'utilisation, est que lorsque vous dites simplement > x.y.z
, vous êtes optimiste: vous supposez qu'à partir de maintenant, jusqu'à toute l'éternité, l'API ne changera jamais. C'est bien sûr une hypothèse assez audacieuse. Cependant, la plupart des projets ont des règles sur le moment où ils sont autorisés à
briser la compatibilité ascendante , et comment ils doivent changer leur numéro de version quand ils font la rétrocompatibilité pause. Vous pouvez encoder ces règles de numérotation de version en utilisant une contrainte pessimiste, et ainsi vous pouvez être sûr que votre code continuera toujours à fonctionner (en supposant que l'auteur de l'autre projet adhère réellement à ses propres règles, ce qui n'est malheureusement pas toujours le cas ).
En d'autres termes, vous pouvez utiliser ce symbole pour garder votre gemme à jour avec toutes les mises à jour mineures et éviter de faire une mise à jour majeure qui pourrait casser votre application.
Par exemple "~> 1.2" mettra à jour votre gem à 1.3 (si une telle version est publiée) mais il ne le mettra pas à jour à 2.0
Je pense que les documents de bundler résument le mieux ceci:
Le spécificateur ~> a une signification particulière, mieux illustrée par l'exemple. ~> 2.0.3 est identique à> = 2.0.3 et <2.1. ~> 2.1 est identique à> = 2.1 et <3.0. ~> 2.2.beta correspondra aux versions préliminaires comme 2.2.beta.12.
Il correspond à n'importe quelle version qui a la même partie majeure / mineure. Cela signifie dans ce cas que haml ~> 2.2.8 correspondra à n'importe quelle version 2.2.x.
Cela peut être utilisé pour s'assurer qu'un changement de rupture d'API dans une nouvelle gemme n'entraîne pas de dépendance à ce gemme nouvellement mais modifié qui briserait hanna dans ce cas.
~> 2.0
et ~> 2.0.0
- l'ancien correspond à 2.0, 2.1, 2.2.7 et tout le reste jusqu'à (mais non compris) 3.0. Ce dernier correspond à 2.0, 2.0.1, 2.0.999 et tout le reste jusqu'à (mais non compris) 2.1.
~> 2.2.8
vous ne correspond « tout 2.2.x version » comme les demandes de réponse, mais seulement avec les versions 2.2.x x ≥ 8. OIEau: la réponse est au mieux encore plus incomplètes, en bordure incorrecte et certainement trompeur.