Убедитесь, что у вас установлена ​​последняя версия CocoaPods.

$ pod update PODNAME был представлен недавно.

Дополнительную информацию см. в этой теме:

обновление пакета $

Когда вы запустите pod update SomePodName, CocoaPods попытается найти обновленную версию pod SomePodName, не принимая во внимание версию, указанную в Podfile.lock. Он обновит модуль до последней возможной версии (при условии, что она соответствует ограничениям версии в вашем подфайле).

Если вы запустите обновление модуля без имени модуля, CocoaPods обновит каждый модуль, указанный в вашем подфайле, до последней возможной версии.

Чтобы установить один модуль без обновления существующих, добавьте этот модуль в свой подфайл и используйте:

pod install --no-repo-update

Чтобы удалить/обновить конкретный модуль, выполните следующие действия:

pod update POD_NAME

Проверено!

It's 2015

Так как pod update SomePod затрагивает все в последних версиях Cocopods, я нашел обходной путь.

Выполните следующие шаги:

1. Удалить SomePod из Podfile

2. Беги pod install

модули теперь удалят SomePod из нашего проекта и из файла Podfile.lock.

3. Верните SomePod в Podfile

4. Запустите pod install еще раз

На этот раз последняя версия нашего модуля будет установлена ​​и сохранена в папке Podfile.lock.

просто говорю:

pod install - для установки новых подов,

pod update - для обновления существующих модулей,

pod update podName - для обновления только определенного модуля, не касаясь других модулей,

pod update podName versionNum - для обновления / ПОНИЖЕНИЯ определенного модуля, не касаясь других модулей.

Вы никогда не сможете получить 100% изоляцию. Поскольку у модуля могут быть некоторые общие зависимости, и если вы попытаетесь обновить свой единственный модуль, он также обновит зависимости других модулей. Если это нормально, то:

тл; др использовать:

pod update podName

Почему? Читай ниже.

• pod update НЕ будет уважать podfile.lock. Он переопределит его, относящийся к этому отдельному пакету.
• pod install будет уважать podfile.lock, но попытается установить каждый pod, упомянутый в podfile, на основе версий, к которым он заблокирован (в Podfile.lock).

Эта диаграмма помогает лучше понять различия:

Основная проблема связана с ~>, также известным как оптимистичный оператор.

Использование точных версий в Podfile недостаточно

Некоторые могут подумать, что указания точных версий своих модулей в их Podfile, например pod 'A', '1.0.0', достаточно, чтобы гарантировать, что у каждого пользователя будет та же версия, что и у других людей в команде.

Затем они могут даже использовать pod update, даже просто добавляя новый модуль, думая, что никогда не рискуют обновить другие модули, потому что они привязаны к определенной версии в Podfile.

Но на самом деле этого недостаточно, чтобы гарантировать, что user1 и user2 в нашем вышеприведенном сценарии всегда будут получать одну и ту же версию всех своих модулей.

Один типичный пример: модуль A имеет зависимость от модуля A2, объявленного в A.podspec как dependency 'A2', '~> 3.0'. В таком случае использование модуля 'A', '1.0.0' в вашем подфайле действительно заставит пользователей user1 и user2 всегда использовать версию 1.0.0 модуля A, но:

• user1 может получить модуль A2 версии 3.4 (поскольку это была последняя версия A2 на тот момент)
• в то время как когда user2 запускает pod install при присоединении к проекту позже, он может получить pod A2 в версии 3.5 (поскольку сопровождающий A2 мог тем временем выпустить новую версию). Вот почему единственный способ убедиться, что каждый член команды работает с одними и теми же версиями всех модулей на каждом компьютере, — это использовать Podfile.lock и правильно использовать pod install вместо pod update.

Весь приведенный выше отрывок был получен из установки модуля и обновления модуля.

Я также настоятельно рекомендую посмотреть что делает podfile.lock

Просто небольшое уведомление.

pod update POD_NAME

будет работать, только если этот модуль уже установлен. В противном случае вам придется обновить их все с помощью

pod update

команда

Я использую cocoapods version 1.0.1, а pod update name-of-pod работает отлично. Никакие другие модули не обновляются, только тот, который вы вводите.

Это немного необычно и вряд ли это то, с чем имел дело OP, но pod update <podname> не будет работать во всех случаях, если вы используете локальный модуль на своем компьютере.

В этой ситуации единственное, что заставит pod update работать, — это изменение файла podspec. Однако внесение изменений также позволит pod install работать.

В этой ситуации вы можете просто изменить что-то незначительное, например описание или сводку, на одну букву, а затем успешно запустить команду установки или обновления.

pod update POD_NAME обновит последний модуль, но не обновит файл Podfile.lock.

Таким образом, вы можете обновить свой подфайл определенной версией вашего модуля, например pod 'POD_NAME', '~> 2.9.0', а затем использовать команду pod install

Позже вы можете удалить конкретное наименование версии из своего подфайла и снова использовать pod install. Это поможет обновлять Podfile.lock.