Xcode versioning de construction Paramètres sur les frameworks

Question

Je travaille sur un framework iOS basé sur le modèle suivant: https://github.com/jverkoey/ios-framework

Maintenant, je dois polir un peu et configurer le système de versioning avec le numéro de construction / marketing approprié.

Ce projet de cadre a 3 cibles, la 1ère qui génère une bibliothèque statique, une 2ème qui génère un bundle de ressources et une 3ème cible qui est une cible agrégée pour la bibliothèque statique et le bundle de ressources. Mon premier problème est donc de déterminer la cible que je dois configurer les paramètres de construction de versioning (ou si je dois configurer toutes les cibles).

Ma deuxième question est quels sont les paramètres que je devrais configurer et ce qu'ils signifient:

Version du projet actuelle => Est-ce la version de construction ou la version marketing? Donc, si je publie des applications avec des versions comme: 1.2.3.4, dois-je définir 4? ou 1.2.3? ou 1.2.3.4?

Noms de fichier source généré par le versioning Source => Le nom du fichier .c généré qui contient le numéro de construction entier je suppose?

Variables de version générée => Qu'est-ce que c'est?

Nom de version préfixe => un préfixe du nom de la variable qui contient le numéro de construction

Nom du versioning suffixe => un suffixe pour le nom de la variable qui contient le numéro de construction

Système de version: tout le monde utilise Apple Generic, donc je suppose que c'est le seul disponible

Version de nom d'utilisateur: qu'est-ce que c'est?

Il existe d'autres paramètres comme la "version Framework" dans la section "Packaging" qui devrait toujours utiliser "un" Je suppose sur iOS (comme ce sont en fait des frameworks statiques, la version n'a pas d'importance)? Et pour les paramètres "Version de compatibilité" / "Version de la bibliothèque actuelle" de la section "Linking", dois-je les configurer uniquement sur la cible de bibliothèque statique? Ou sont-ils utilisés par l'application reliant la bibliothèque?

Answer 1

Sauf si vous construisez un cadre commercial et de source fermée, Je recommanderais vraiment d'utiliser Cocoapodes. Il s'occupera des dépendances, des ressources, du versioning, de la mise à jour, de l'installation, etc. Tous les gros maux de tête à mesure que votre bibliothèque change au fil du temps.

Même si vous souhaitez distribuer des binaires uniquement pour le code de source fermée, vous pouvez construire les binaires avec des cocoapodes, puis les distribuer avec un autre PODSpec. Vous éviterez également l'intégration d'un autre code de bibliothèques, ce qui est une pratique vraiment mauvaise mais courante.

Quant au versioning, vous pouvez vérifier ici.

---

Revenir à la fabrication de la bibliothèque statique ...

La version n'est pas visible de l'application et ne serait que de la documentation, donc je pense que vous devriez l'ajouter à toutes vos cibles. Si vous voulez vraiment pouvoir détecter la version de votre bibliothèque lors de l'exécution, vous devrez proposer une méthode de classe ou une variable globale comme [MyLibrary version].

La documentation de ces clés est incluse dans Xcode ou vous pouvez simplement en sélectionner une et vérifier le volet "Aide rapide":

Answer 2

Apple a une documentation assez approfondie pour la construction et la distribution de cadres.

La Guide de programmation du cadre couvre la plupart du terrain dont vous avez besoin. Si vous souhaitez des informations plus spécifiques sur la façon dont les outils du développeur utilisent les informations de votre projet, consultez la page manuelle pour agvtool, l'outil que Xcode utilise avec le système de versioning Apple.

Vous devriez également être intéressé par le Codage Guidelines for Cocoa, qui couvre également les meilleures pratiques pour les cadres.