tl; dr utiliser:
pod update podName
Pourquoi? Lire ci-dessous.
pod update
ne respectera PAS le podfile.lock
. Il la remplacera.
pod install
respectera la podfile.lock
Ce diagramme permet de mieux comprendre les différences:
Le problème majeur vient de l' ~>
opérateur aka optimiste .
L'utilisation de versions exactes dans le Podfile
n'est pas suffisante
Certains pourraient penser qu'en spécifiant les versions exactes de leurs pods dans leur Podfile
, comme pod 'A', '1.0.0'
, c'est suffisant pour garantir que chaque utilisateur aura la même version que les autres personnes de l'équipe.
Ensuite, ils pourraient même utiliser pod update
, même lors de l'ajout d'un nouveau pod, pensant que cela ne risquerait jamais de mettre à jour d'autres pods car ils sont fixés sur une version spécifique dans le Podfile
.
Mais en fait, cela ne suffit pas pour garantir que user1 et user2 dans notre scénario ci-dessus obtiendront toujours la même version exacte de tous leurs pods.
Un exemple typique est si le pod A
a une dépendance sur le pod A2
- déclaré en A.podspec
tant que dependency 'A2', '~> 3.0'
. Dans ce cas, l'utilisation de pod 'A', '1.0.0'
dans votre Podfile forcera en effet user1 et user2 à toujours utiliser la version 1.0.0 du pod A, mais:
- user1 pourrait se retrouver avec pod
A2
dans la version 3.4
(parce que c'était A2
la dernière version de l'époque)
- tandis que lorsque user2 s'exécute
pod install
en rejoignant le projet plus tard, ils peuvent obtenir le pod A2
dans la version 3.5
(car le responsable de A2
peut avoir publié une nouvelle version entre-temps). C'est pourquoi la seule façon de s'assurer que chaque membre de l'équipe travaille avec les mêmes versions de tous les pods sur l'ordinateur de chacun est d'utiliser Podfile.lock
et d'utiliser correctement pod install
vs pod update
..
L'extrait ci-dessus est dérivé de l' installation du pod contre la mise à jour du pod
Je recommande également fortement de regarder ce que podfile.lock
fait
podfile.lock
. Voir le lien et la vidéo auxquels il fait référence.