Question Version vs construire dans Xcode


J'ai une application que j'ai développée avec Xcode 3 et j'ai récemment commencé à éditer avec Xcode 4. Dans le résumé cible, j'ai le formulaire cible de l'application iOS avec les champs: identifiant, version, build, devices et cible de déploiement. Le champ de version est vide et le champ de construction est 3.4.0 (qui correspond à la version de l'application depuis que je travaillais encore 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 ma mise à niveau vers Xcode 4?


604
2017-07-27 21:48


origine


Réponses:


Apple sorte de réarrangé / réorienté les champs.

À l'avenir, si vous regardez dans l'onglet Info pour votre cible d'application, vous devez utiliser la "version de chaîne de chaînes, courte" comme version (par exemple, 3.4.0) et "version de regroupement" comme votre construction (par exemple 500 ou 1A500 ). Si vous ne les voyez pas tous les deux, vous pouvez les ajouter. Ceux-ci seront mappés aux bonnes zones Version et Build de l'onglet Résumé; ce sont les mêmes valeurs.

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

La version est généralement utilisée comme si vous l'utilisiez avec Xcode 3. Je ne suis pas sûr du niveau que vous demandez à propos de la différence Version / Build, donc je vais y répondre philosophiquement.

Il y a toutes sortes de régimes, mais un populaire est:

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

  • Version majeure - Changements majeurs, refonte et fonctionnalité changements
  • Version mineure - Améliorations mineures, ajouts à la fonctionnalité
  • Révision - Un numéro de patch pour les corrections de bogues

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

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

  • Version 1.0.0 pourrait être build 542. Il a fallu 542 builds pour arriver à un Version 1.0.0.
  • La version 1.0.1 pourrait être construite 578.
  • La version 1.1.0 pourrait être la version 694.
  • La version 2.0.0 pourrait être construite 949.

D'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. Ce sont les numéros de version réels du logiciel, par opposition aux valeurs utilisées pour le marketing.

Si vous allez à Xcode menu> A propos de Xcode, vous verrez les numéros de version et de construction. Si vous frappez le Plus d'informations... bouton, vous verrez un tas de différentes versions. Depuis le Plus d'informations... bouton a été supprimé dans Xcode 5, cette information est également disponible à partir du Logiciel> Développeur section de Informations sur le système application, disponible en ouverture Pomme menu> À propos de ce Mac > Rapport système ....

Par exemple, Xcode 4.2 (4C139). La version 4.2 de Marketing est Build version majeure 4, Build version C et Build numéro 139. La version suivante (vraisemblablement 4.3) sera probablement Build version 4D, et le numéro de Build recommencera à 0 et augmentera à partir de là.

Les numéros de version et de build de l'iPhone Simulator sont les mêmes, tout comme les iPhones, les Mac, etc.

  • 3.2: (7W367a)
  • 4,0: (8A400)
  • 4.1: (8B117)
  • 4.2: (8C134)
  • 4.3: (8H7)

Mettre à jour: Sur demande, voici les étapes pour créer un script qui s'exécute chaque fois que vous construisez votre application dans Xcode pour lire le numéro de build, l'incrémenter et le réécrire dans l'application {App}-Info.plist fichier. Des étapes supplémentaires sont facultatives si vous souhaitez écrire vos numéros de version / build dans votre Settings.bundle/Root*.plist des dossiers).

Ceci est étendu de l'article how-to 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 du projet.
  3. Sur le côté gauche du volet de la fenêtre centrale, cliquez sur votre application sous le CIBLES titre. Vous devrez configurer cette configuration pour chaque cible de projet.
  4. Sélectionnez le Construire des phases languette.
    • Dans Xcode 4, en bas à droite, cliquez sur Ajouter une phase de construction bouton 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 génération de script d'exécution.
  5. Glisser-déposer le nouveau Script de lancement phase pour le déplacer juste avant la Copier les ressources du regroupement phase (lorsque le fichier app-info.plist sera livré avec votre application).
  6. Dans le nouveau Script de lancement phase, ensemble coquille: /bin/bash.
  7. Copiez et collez le texte suivant dans la zone de script pour les nombres de génération entiers:

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

    Comme l'a souligné @Bdebeez, le Outil de version générique Apple (agvtool) est également disponible. Si vous préférez l'utiliser à la place, il y a quelques choses à changer en premier:

    • Sélectionnez le Paramètres de construction languette.
    • Sous le Versioning section, définissez Version actuelle du projet au numéro de build initial que vous souhaitez utiliser, par exemple, 1.
    • Retour sur le Construire des phases onglet, faites glisser et déposez votre Script de lancement phase après la Copier les ressources du regroupement phase pour éviter une condition de concurrence en essayant de construire et mettre à jour le fichier source qui inclut votre numéro de build.

    Notez qu'avec le agvtool méthode que vous pouvez toujours obtenir des versions échouées / annulées sans erreurs. Pour cette raison, je ne recommande pas d'utiliser agvtool avec ce script.

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

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

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

  8. 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. Note: Changez le PreferenceSpecifiers valeurs pour correspondre à vos paramètres. PreferenceSpecifiers:2 signifie regarder l'élément à l'indice 2 sous la PreferenceSpecifiers tableau dans votre fichier plist, donc pour un index 0, c'est le troisième paramètre de préférence dans le 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 ce qui suit à 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
    
  9. Et si vous avez une application universelle pour iPad et iPhone, vous pouvez également définir les paramètres pour le 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
    

1147
2017-08-06 05:55



(Juste en laissant ceci ici pour ma propre référence.) Cela 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];
}

Dans Swift

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
2017-09-05 14:18



Le numéro de build est un nombre interne qui indique l'état actuel de l'application. Il diffère du numéro de version en ce qu'il n'est généralement pas orienté utilisateur et ne dénote aucune différence / caractéristiques / mises à niveau comme le ferait un numéro de version.

Pensez-y comme ceci:

  • Construire (CFBundleVersion): Le numéro de la construction. Habituellement, vous commencez à 1 et augmentez de 1 avec chaque build de l'application. Il permet rapidement des comparaisons de construction plus récentes et indique le sens de progression de la base de code. Ceux-ci peuvent être extrêmement précieux lorsque vous travaillez avec QA et avoir besoin d'être sûr que les bogues sont enregistrés dans les bonnes versions.
  • Version marketing (CFBundleShortVersionString): Le numéro que vous utilisez pour indiquer cette version de votre application. Habituellement, cela suit 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 importantes.

Pour l'utiliser efficacement dans vos projets, Apple fournit un excellent outil appelé agvtool. Je recommande fortement d'utiliser ceci car il est BEAUCOUP plus simple que de scripter les changements de plist.  Il vous permet de définir facilement le numéro de build et la version marketing. Il est particulièrement utile lors de l'écriture de scripts (par exemple, en mettant facilement à jour le numéro de build de chaque build ou même en demandant 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 nombre de build à 1)
    • agvtool new-marketing-version 1.0 (définissez la version Marketing sur 1.0)

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


47
2017-12-24 01:37



Le script pour auto-incrémenter le numéro de build dans la réponse ci-dessus n'a pas fonctionné pour moi si le nombre de build est une valeur à virgule flottante, donc je l'ai modifié un peu:

#!/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
2018-02-08 15:47



Le numéro de version marketing est pour les clients, appelés numéro de version. Ça commence avec 1.0 et monte pour les mises à jour majeures à 2,0, 3,0, pour des mises à jour mineures 1.1, 1,2 et pour les corrections de bugs à 1.0.1, 1.0.2 . Ce numéro est orienté sur les versions et les nouvelles fonctionnalités.

le numéro de build est principalement le nombre interne de buildsqui ont été faites jusque-là. Mais certains utilisent d'autres nombres comme le numéro de la succursale du référentiel. Ce nombre devrait être unique distinguer les différents presque les mêmes constructions.

Comme vous pouvez le voir, le numéro de build n'est pas nécessaire et c'est à vous de décider numéro de build vous voulez utiliser. Donc, si vous mettez à jour votre Xcode à une version majeure, le construire le champ est vide. le version le champ peut ne pas être vide!


Pour obtenir le construire nombre en tant que NSString variable:

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

Pour obtenir le version nombre en tant que NSString variable:

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

Si tu veux tous les deux dans une 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 build comme un nombre décimal en plaçant ce qui suit dans le Run script phase de construction dans les 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 build utilise 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
2017-10-28 07:33



Merci à @nekno et @ ale84 pour de bonnes réponses.

Cependant, j'ai modifié le script de @ ale84 pour incrémenter les nombres de build pour le virgule flottante.

La valeur de incl peut être modifiée en fonction de vos exigences de format flottant. 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
2018-02-02 08:14



une autre façon est de 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
2018-01-17 15:05