docs - ruby installer 32 bit




Signification de tilde-plus-que(~>) dans l'exigence de version? (3)

Quelle est la signification de l'exigence de version ~> dans les spécifications de gem?

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

En d'autres termes, vous pouvez utiliser ce symbole pour garder votre gem mis à jour avec toutes les mises à jour mineures et éviter de faire une mise à jour majeure qui peut casser votre application.

Par exemple "~> 1.2" mettra à jour votre gemme à 1.3 (si une telle version est publiée) mais ne la mettra pas à jour vers 2.0


Il correspond à toute version ayant la même partie majeure / mineure. Cela signifie dans ce cas que haml ~> 2.2.8 correspondra à n'importe quelle version de 2.2.x.

Cela peut être utilisé pour s'assurer qu'une API qui brise un changement dans une nouvelle gemme, ne résulte pas en ce gemme nouvellement mais modifié qui casserait hanna dans ce cas.


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, afin de remplir la contrainte, un numéro de version doit satisfaire aux deux conditions suivantes

  1. Les premières n-1 parties du numéro de version doivent être identiques aux premières n-1 parties de la contrainte (par exemple 1.x ou 3.5.6.x , mais pas 0.x ou 3.5.7.x ) et

  2. La dernière partie du numéro de version doit être supérieure ou égale à la dernière partie de la contrainte (par exemple, les correspondances 1.9999 et 3.5.6.2 , mais pas 1.2 ou 3.5.6.1 ).

En d'autres termes

~> x1.x2.x3. … .xn-2.xn-1.xn

allumettes

x1.x2.x3. … .xn-2.xn-1.y, y >= xn

La raison pour laquelle on appelle cela une contrainte "pessimiste", et aussi le cas d'utilisation, est que quand vous dites juste > xyz , vous êtes optimiste: vous supposez qu'à partir de maintenant, jusqu'à l'éternité, l'API ne sera jamais changement. 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 à rompre la compatibilité ascendante , et comment ils doivent changer leur numéro de version quand ils sont en rupture de compatibilité. 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 à 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 ).





rubygems