web-dev-qa-db-fra.com

Version vs construction dans Xcode

J'ai une application que j'ai développée avec Xcode 3 et que j'ai récemment commencé à modifier avec Xcode 4. Dans le résumé de la cible, j'ai le formulaire de cible d'application iOS avec les champs suivants: identifiant, version, construction, périphériques et cible de déploiement. Le champ de version est vide et le champ de construction est 3.4.0 (ce qui correspond à la version de l'application de quand j'étais encore en train de modifier avec Xcode 3).

Mes questions sont:

  1. Quelle est la différence entre les champs version et build?

  2. Pourquoi le champ de version était-il vide après la mise à niveau vers Xcode 4?

iosxcode
640
chris

Apple a en quelque sorte réarrangé/recyclé les champs.

A l'avenir, si vous regardez dans l'onglet Info pour votre cible d'application, vous devez utiliser "Chaîne de versions d'ensembles, en abrégé" en tant que Version (par exemple, 3.4.0) et "Version en ensemble" en tant que Construction (par exemple, 500 ou 1A500). ). Si vous ne les voyez pas tous les deux, vous pouvez les ajouter. Ceux-ci mapperont vers les zones de texte Version et Build appropriées sous l'onglet Résumé; ce sont les mêmes valeurs.

Lorsque vous affichez l’onglet Informations, si vous cliquez avec le bouton droit de la souris et sélectionnez Afficher les clés/valeurs brutes, vous verrez les noms réels sont CFBundleShortVersionString (Version) et CFBundleVersion (Construire). ).

La version est généralement utilisée comme vous semblez l’avoir utilisée avec Xcode 3. Je ne sais pas à quel niveau vous vous interrogez sur la différence Version/Construire, je vais donc y répondre de façon philosophique.

Il existe toutes sortes de programmes, mais l'un des plus populaires est:

{MajorVersion}. {MinorVersion}. {Révision}

  • Version majeure - Modifications majeures, restructurations et fonctionnalités
  • Version mineure - Améliorations mineures, ajouts à la fonctionnalité
  • Révision - Un numéro de correctif pour les corrections de bugs

Ensuite, la version est utilisée séparément pour indiquer le nombre total de versions pour une version ou pour toute la durée de vie du produit.

De nombreux développeurs commencent le numéro de build à 0, et chaque fois qu'ils construisent, ils augmentent le nombre d'un chiffre, pour toujours. Dans mes projets, j'ai un script qui augmente automatiquement le nombre de versions à chaque construction. Voir les instructions pour cela ci-dessous.

  • La version 1.0.0 pourrait être la version 542. Il a fallu 542 versions pour obtenir la version 1.0.0.
  • La version 1.0.1 pourrait être la version 578.
  • La version 1.1.0 pourrait être la version 694.
  • La version 2.0.0 pourrait être la version 949.

Les autres développeurs, y compris Apple, ont un numéro de build composé d'une version majeure + version mineure + nombre de builds pour la version. Il s’agit des numéros de version des logiciels, par opposition aux valeurs utilisées pour le marketing.

Si vous allez dans Xcode menu> À propos de Xcode, vous verrez les numéros de version et de build. Si vous appuyez sur le bouton Plus d'infos ..., vous verrez un grand nombre de versions différentes. Depuis que le bouton Plus d'infos ... a été supprimé dans Xcode 5, cette information est également disponible dans la section Logiciel> Développeur de Informations système app, disponible en ouvrant le menu Apple> À propos de ce Mac> Rapport système ....

Par exemple, Xcode 4.2 (4C139). La version 4.2 de Marketing est la version majeure 4, la version mineure C et la version 139. La prochaine version (probablement la 4.3) sera probablement la version 4D, et le numéro de version recommencera à 0 et sera incrémenté à partir de là.

Les numéros de version/version de iPhone Simulator sont identiques à ceux des iPhones, Mac, etc.

  • 3.2: (7W367a)
  • 4.0: (8A400)
  • 4.1: (8B117)
  • 4.2: (8C134)
  • 4.3: (8H7)

Mise à jour: À la demande, voici les étapes à suivre pour créer un script qui s'exécute chaque fois que vous créez votre application dans Xcode pour lire le numéro de construction, l'incrémenter et l'écrire dans le fichier {App}-Info.plist de l'application. Il existe des étapes supplémentaires facultatives si vous souhaitez écrire vos numéros de version/construction dans votre fichier Settings.bundle/Root*.plist.

Ceci est étendu à partir de l'article de procédure ici .

Dans Xcode 4.2 - 5.0:

  1. Chargez votre projet Xcode.
  2. Dans le volet de gauche, cliquez sur votre projet tout en haut de la hiérarchie. Cela chargera l’éditeur de paramètres de projet.
  3. Sur le côté gauche du volet de la fenêtre centrale, cliquez sur votre application sous le titre CIBLES. Vous devrez configurer cette configuration pour chaque cible du projet.
  4. Sélectionnez l'onglet Build Phases.
    • Dans Xcode 4, en bas à droite, cliquez sur le bouton Ajouter une phase de construction et sélectionnez Ajouter un script d'exécution.
    • Dans Xcode 5, sélectionnez Éditeur menu> Ajouter une phase de construction> Ajouter une phase de construction de script d'exécution.
  6. Glissez-déposez la nouvelle phase Exécuter le script ​​pour la déplacer juste avant la phase Copier les ressources du bundle (lorsque le fichier app-info.plist sera fourni avec votre application ).
  7. Dans la nouvelle phase Run Script, définissez Shell: /bin/bash.

  8. Copiez et collez les éléments suivants dans la zone de script pour les numéros de construction entiers:

    buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

    Comme @Bdebeez l'a souligné, le outil générique de versioning Apple (agvtool) est également disponible. Si vous préférez l'utiliser à la place, vous devez d'abord modifier quelques points:

    • Sélectionnez l'onglet Paramètres de construction.
    • Dans la section Versioning, définissez Version actuelle du projet ​​sur le numéro de construction initial que vous souhaitez utiliser, par exemple, 1.
    • De retour sur l'onglet Build Phases, glissez-déposez votre phase Run Script ​​après la phase Copier les ressources du paquet ​​afin d'éviter une situation de concurrence critique lorsque vous essayez construire et mettre à jour le fichier source contenant votre numéro de build.

    Remarquez qu'avec la méthode agvtool, vous pouvez toujours obtenir périodiquement des constructions échouées/annulées sans erreur. Pour cette raison, je ne recommande pas d'utiliser agvtool avec ce script.

    Néanmoins, dans votre phase Run Script, vous pouvez utiliser le script suivant:

    "${DEVELOPER_BIN_DIR}/agvtool" next-version -all

    L'argument next-version incrémente le numéro de build (bump est également un alias pour la même chose) et -all met à jour Info.plist avec le nouveau numéro de build.

  9. Et si vous avez un ensemble de paramètres dans lequel vous affichez la version et la construction, vous pouvez ajouter ce qui suit à la fin du script pour mettre à jour la version et la construction. Remarque: Modifiez les valeurs PreferenceSpecifiers pour qu'elles correspondent à vos paramètres. PreferenceSpecifiers:2 signifie que vous regardez l'élément à l'index 2 sous le tableau PreferenceSpecifiers de votre fichier plist. Ainsi, pour un index basé sur 0, il s'agit du troisième paramètre de préférence du tableau. 

    productVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "$INFOPLIST_FILE")
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist

    Si vous utilisez agvtool au lieu de lire le Info.plist directement, vous pouvez ajouter les éléments suivants à votre script:

    buildNumber=$("${DEVELOPER_BIN_DIR}/agvtool" what-version -terse)
productVersion=$("${DEVELOPER_BIN_DIR}/agvtool" what-marketing-version -terse1)
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist

  10. Et si vous avez une application universelle pour iPad et iPhone, vous pouvez également définir les paramètres du fichier iPhone:

    /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root~iphone.plist    
/usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root~iphone.plist
1198
nekno

(En laissant ceci ici pour ma propre référence.) Ceci affichera la version et la construction des champs "version" et "build" que vous voyez dans une cible Xcode:

- (NSString*) version {
    NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
    NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
    return [NSString stringWithFormat:@"%@ build %@", version, build];
}

En rapide

func version() -> String {
    let dictionary = NSBundle.mainBundle().infoDictionary!
    let version = dictionary["CFBundleShortVersionString"] as? String
    let build = dictionary["CFBundleVersion"] as? String
    return "\(version) build \(build)"
}
71
Dan Rosenstark

Le numéro de build est un numéro interne qui indique l'état actuel de l'application. Il diffère du numéro de version en ce sens qu’il ne fait généralement pas face aux utilisateurs et ne dénote aucune différence/fonctionnalités/mises à niveau comme le ferait un numéro de version.

Pensez-y comme ceci:

  • Build (CFBundleVersion): numéro de la construction. Habituellement, vous commencez à 1 et augmentez de 1 à chaque version de l'application. Il permet rapidement de comparer la construction la plus récente et indique le sens de progression de la base de code. Celles-ci peuvent s'avérer extrêmement utiles lorsque vous travaillez avec le contrôle qualité et que vous devez vous assurer que les bogues sont consignés dans les versions correctes.
  • Version marketing (CFBundleShortVersionString): numéro personnel que vous utilisez pour désigner cette version de votre application. Cela suit généralement un schéma de version Major.minor (par exemple, MyAwesomeApp 1.2) pour permettre aux utilisateurs de savoir quelles versions sont des mises à jour de maintenance plus petites et quelles sont les nouvelles fonctionnalités les plus intéressantes.

Pour utiliser ceci efficacement dans vos projets, Apple fournit un excellent outil appelé agvtool. Je recommande vivement d'utiliser cette option, car elle est BEAUCOUP plus simple que de créer des scripts pour modifier les modifications apportées à la liste de programmes. Il vous permet de définir facilement le numéro de build et la version marketing. Cela est particulièrement utile lors de la création de scripts (par exemple, mettre à jour facilement le numéro de build sur chaque build ou même demander quel est le numéro de build actuel). Il peut même faire des choses plus exotiques comme marquer votre SVN pour vous lorsque vous mettez à jour le numéro de build.

Pour l'utiliser:

  • Définissez votre projet dans Xcode, sous Versioning, pour utiliser "Apple Generic".
  • Dans le terminal
    • agvtool new-version 1 (définissez le numéro de build sur 1)
    • agvtool new-marketing-version 1.0 (définissez la version de Marketing sur 1.0)

Voir la page de manuel de agvtool pour une tonne de bonnes informations

51
Bdebeez

Le script d'auto-incrémentation du numéro de build dans la réponse ci-dessus ne fonctionnait pas pour moi si le numéro de build était une valeur à virgule flottante, je l'ai donc légèrement modifiée:

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=`echo $buildNumber +1|bc`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"
25
ale84

Le numéro de version marketing est destiné aux clients, appelé numéro de version. Il commence par 1.0 et monte pour les mises à jour majeures à 2.0 , 3.0 , pour les mises à jour mineures de 1.1 , 1.2 et pour les corrections de bugs apportées à 1.0.1 , 1.0. 2 . Ce nombre est orienté sur les versions et les nouvelles fonctionnalités.

Le numéro de build est principalement le nombre interne de builds qui ont été créés jusque-là. Mais certains utilisent d'autres numéros comme le numéro de branche du référentiel. Ce nombre doit être unique pour distinguer les différentes versions presque identiques.

Comme vous pouvez le constater, le numéro de construction n'est pas nécessaire et vous pouvez choisir le numéro de construction vous souhaitez utiliser. Donc, si vous mettez à jour votre Xcode vers une version majeure, le champ build est vide. Le champ version peut ne pas être vide !.

Pour obtenir le nombre build sous la forme d'une variable NSString:

NSString * appBuildString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"];

Pour obtenir le nombre version sous la forme d'une variable NSString:

NSString * appVersionString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"];

Si vous voulez les deux en un NSString:

NSString * versionBuildString = [NSString stringWithFormat:@"Version: %@ (%@)", appVersionString, appBuildString];

Ceci est testé avec Xcode Version 4.6.3 (4H1503) . Le numéro de build est souvent écrit entre parenthèses/accolades. Le numéro de build est en hexadécimal ou décimal.

buildandversion

Dans Xcode, vous pouvez auto-incrémenter le numéro de compilation en tant que nombre décimal en plaçant ce qui suit dans la phase de construction Run script dans le paramètres du projet

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

Pour hexadécimal numéro de construction, utilisez ce script

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$((0x$buildNumber)) 
buildNumber=$(($buildNumber + 1)) 
buildNumber=$(printf "%X" $buildNumber)
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

project_settings

21
Binarian

Merci à @nekno et @ ale84 pour d'excellentes réponses.

Cependant, j’ai modifié le script de @ ale84 afin d’incrémenter les numéros de build pour les virgules flottantes.

la valeur de incl peut être modifiée en fonction de vos exigences en matière de format flottant. Pour par exemple: si incl = .01, le format de sortie serait ... 1.19, 1.20, 1.21 ...

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
incl=.01
buildNumber=`echo $buildNumber + $incl|bc`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"
6
iHS

vous pouvez également définir le numéro de version dans appDelegate didFinishLaunchingWithOptions:

- (BOOL)application:(UIApplication *)application         didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
     NSString * ver = [self myVersion];
     NSLog(@"version: %@",ver);

     NSUserDefaults* userDefaults = [NSUserDefaults standardUserDefaults];
     [userDefaults setObject:ver forKey:@"version"];
     return YES;
}

- (NSString *) myVersion {
    NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
    NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
    return [NSString stringWithFormat:@"%@ build %@", version, build];
}
1
mark VanderWiele