Настройки сборки версий Xcode в фреймворках

Question

Я работаю над платформой iOS, основанной на следующем шаблоне : https://github.com/jverkoey/iOS-Framework

Теперь мне нужно немного отполировать и настроить систему управления версиями с соответствующим номером сборки / маркетинга.

Этот рамочный проект имеет 3 цели: 1-я, которая генерирует статическую библиотеку, 2-я, которая генерирует пакет ресурсов, и 3-я цель, которая является совокупной целью для статической библиотеки и пакета ресурсов.Итак, моя первая проблема состоит в том, чтобы определить, для какой цели я должен настроить параметры сборки управления версиями (или я должен настроить все цели).

Мой 2-й вопрос заключается в том, какие настройки я должен настроить и что они означают :

Текущая версия проекта => Это версия для сборки или маркетинговая версия?Итак, если я выпускаю приложения с такими версиями, как :1.2.3.4, должен ли я установить 4?или 1.2.3 ?или 1.2.3.4 ?

Сгенерированное исходное имя файла управления версиями => Имя сгенерированного файла .c, которое, я полагаю, содержит целочисленный номер сборки?

Сгенерированные переменные управления версиями => Что это?

Префикс имени управления версиями => Префикс для имени переменной, содержащей номер сборки

Суффикс имени управления версиями => Суффикс для имени переменной, содержащей номер сборки

Система управления версиями:Все используют Apple Generic, так что я думаю, что это единственный доступный

Имя пользователя для управления версиями:Что это ?

Есть другие настройки, такие как "Версия фреймворка" в разделе "Упаковка", которые, я думаю, всегда должны использовать "A" на iOS (поскольку они на самом деле являются статическими фреймворками, версия не имеет значения)?А что касается настроек "Версия совместимости" / "Текущая версия библиотеки" раздела "Связывание", должен ли я настроить их только для целевой статической библиотеки?или они используются приложением , связывающим библиотеку?

Answer 1

Если только вы не создаете коммерческий фреймворк с закрытым исходным кодом, Я бы действительно рекомендовал использовать Кокосовые стручки.Он позаботится о зависимостях, ресурсах, управлении версиями, обновлении, установке и т.д.Все это большая головная боль, поскольку ваша библиотека меняется с течением времени.

Даже если вы хотите распространять двоичные файлы - только для закрытого исходного кода, вы могли бы создавать двоичные файлы с помощью CocoaPods, а затем распространять их с другим podspec.Кроме того, вы избежите встраивания кода других библиотек, что является действительно плохой, но распространенной практикой.

Что касается управления версиями, вы можете проверить здесь.

---

Возвращаясь к созданию статической библиотеки...

Версия не видна из приложения и будет просто документацией, поэтому я думаю, вам следует добавить ее ко всем вашим целям.Если вы действительно хотите иметь возможность определять версию своей библиотеки во время выполнения, вам нужно будет создать метод класса или глобальную переменную, например [MyLibrary version].

Документация для этих ключей включена в Xcode, или вы можете просто выбрать один из них и проверить панель "Быстрая справка":

Answer 2

Apple имеет довольно обширную документацию для строительства и распределения рамок.

А Руководство по программированию фреймворка охватывает большую часть необходимой почвы. Если вам нужна более конкретная информация о том, как инструменты разработчика используют информацию в вашем проекте, посмотрите на страницу руководства для agvtool, инструмент, который использует Xcode с системой версий Apple.

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