У меня есть список библиотек в моем файле Pod. Я решил добавить новый файл Pod. Но я хочу сохранить все свои предыдущие версии без обновлений и просто установить (добавить) эту одну библиотеку
pod 'JSAnimatedImagesView', '~> 1.0.0'
so pod update и pod install обновить все библиотеки до более новых версий, но я не хочу их обновлять, просто установите pod 'JSAnimatedImagesView', '~> 1.0.0'
pod install --no-repo-update
Это устанавливает новые элементы без обновления существующих репозиториев (версий или нет).
Это также быстрее, если у вас много репо и требуется быстрая установка нового элемента.
Если вы не хотите обновлять определенные библиотеки, вы должны заблокировать их в версиях, которые вы хотите сохранить
pod 'AFNetworking', '1.2.0'
pod 'JSAnimatedImagesView', '~> 1.0.0'
Сохраняйте AFNetworking на V1.2.0, но получите последний JSAnimatedImagesView
Это делает перенос podfile в другие места (и разработчики) и избавляет вас от забывания, чтобы вернуть ваш файл подкачки, пока вы не собираетесь обновлять модули
Вы можете попробовать использовать команду update https://guides.cocoapods.org/terminal/commands.html#pod_update
pod update [POD_NAMES ...]
Обновляет объекты, идентифицированные указанным POD_NAMES. Если POD_NAMES не заданы, он обновляет все Pod, игнорируя содержимое Podfile.lock.
При запуске с проектом, вероятно, вы захотите использовать последнюю версию Pod. Если это так, просто опустите требования к версии.
pod 'SSZipArchive'
Позже в проекте вы можете захотеть заморозить определенную версию Pod, и в этом случае вы можете указать этот номер версии.
pod 'Objection', '0.9'
Дополнительная информация http://guides.cocoapods.org/syntax/podfile.html#pod
Добавить новый pod repo в ваш podfile и использовать следующую команду
pod install
Источник формы примера pod install vs. pod update
Пример сценария
Вот пример сценария, иллюстрирующий различные варианты использования, которые могут возникнуть в течение жизни проекта.
Этап 1: User1 создает проект
user1 создает проект и хочет использовать элементы A, B, C. Они создают Podfile с этими контейнерами и запускают установку pod.
Это установит элементы A, B, C, которые мы скажем, все в версии 1.0.0.
Подфайл .lock будет отслеживать это и отметить, что A, B и C установлены как версия 1.0.0.
Кстати, поскольку в первый раз они запускают установку pod и проект Pods.xcodeproj еще не существует, команда также создаст Pods.xcodeproj и .xcworkspace, но это побочный эффект команды, а не его основной роли.
Этап 2: User1 добавляет новый pod
Позже пользователь1 хочет добавить pod D в свой подфайл.
Затем они должны запустить pod install после этого, так что, даже если тестеран pod B выпустил версию 1.1.0 своего модуля с момента первого выполнения установки pod, проект будет продолжать использовать версию 1.0.0 - потому что только user1 хочет добавить pod D, не рискуя неожиданным обновлением до B.
Что, когда некоторые люди ошибаются, потому что они используют обновление pod здесь, возможно, думая об этом как "Я хочу обновить свой проект новыми модулями"? - вместо использования pod install - для установки новых модулей в проекте.
Этап 3: User2 присоединяется к проекту
Тогда пользователь2, который никогда не работал над проектом раньше, присоединяется к команде. Они клонируют репозиторий, затем используют установку pod.
Содержимое Podfile.lock(которое должно быть привязано к репо git) гарантирует, что они получат одни и те же файлы, с теми же версиями, что и пользователь1.
Даже если теперь доступна версия 1.2.0 pod C, пользователь2 получит pod C в версии 1.0.0. Потому что это то, что зарегистрировано в Podfile.lock. pod C заблокирован до версии 1.0.0 под Podfile.lock(отсюда и название этого файла).
Этап 4: Проверка новых версий модуля
Позже пользователь1 хочет проверить, доступны ли какие-либо обновления для контейнеров. Они запускают pod устаревшие, которые скажут им, что pod B имеет новую версию 1.1.0, а pod C выпустила новую версию 1.2.0.
user1 решает, что они хотят обновить pod B, но не pod C; поэтому они будут запускать обновление pod p, которое обновит B от версии 1.0.0 до версии 1.1.0 (и соответственно обновит Podfile.lock), но сохранит pod C в версии 1.0.0 (и не обновит его до версии 1.2. 0).