Ich habe ein Shell-Skript als Teil meines Xcode-Erstellungsprozesses verwendet, um die Erstellungsnummer in der Plist- Datei zu erhöhen . Allerdings stürzt Xcode 4.2.1 häufig ab (mit einem Fehler bezüglich des Ziels, das nicht zu einem Projekt gehört; ich vermute Das Ändern der Plist- Datei verwirrt Xcode in gewisser Weise.

Das Shell-Skript hat dies getan, sodass die Build-Nummer nur dann erhöht wird, agvtoolwenn eine Datei neuer als die Plist- Datei ist (also hat nur das Erstellen den Wert nicht erhöht):

if [ -n \"`find ProjDir -newer ProjDir/Project-Info.plist`\" ]; then agvtool -noscm next-version -all; else echo \"Version not incremented\"; fi

Gibt es eine Möglichkeit, die Build-Nummer (in der Plist- Datei oder anderswo) zu erhöhen , ohne Xcode zu beschädigen?

FINAL EDIT : Ich mache jetzt solche Sachen mit einem Python-Skript, das ich gerade auf Github veröffentlicht habe . Es ist nicht gut dokumentiert, sollte aber nicht schwer zu erarbeiten sein. Als Bonus enthält dieses Repo auch ein nützliches Skript, um Bibliotheken von Drittanbietern automatisch in ein App-Bundle zu bündeln.

Wenn ich Ihre Frage richtig verstehe, möchten Sie die Project-Info.plistDatei ändern , die Teil der Standardprojektvorlage von Xcode ist.

Der Grund, warum ich dies frage, ist, dass es Project-Info.plistnormalerweise unter Versionskontrolle steht. Wenn Sie es ändern, bedeutet dies, dass es als geändert markiert wird.

Wenn dies für Sie in Ordnung ist, aktualisiert das folgende Snippet die Build-Nummer und markiert die Datei als im Prozess geändert. Dabei get_build_numberbefindet sich ein Skript (dh ein Platzhalter in diesem Beispiel), um die (möglicherweise inkrementierte) Build-Nummer zu erhalten, die Sie haben Möchte benutzen:

#!/bin/sh

# get_build_number is a placeholder for your script to get the latest build number
build_number = `get_build_number`

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion ${build_number}" ProjDir/Project-Info.plist

Mit PlistBuddy können Sie einen beliebigen Schlüssel in einer Plist-Datei festlegen, nicht nur die Versionsnummer. Sie können alle gewünschten Plist-Dateien erstellen und bei Bedarf in die Ressourcen aufnehmen. Sie können dann aus dem Bundle eingelesen werden.

Wenn Sie die Version im Info-Bereich und an anderen Stellen anzeigen möchten, können Sie auch die Einstellungen CFBundleGetInfoStringund überprüfen CFBundleShortVersionString.

Ich habe mit vielen Antworten auf diese Frage herumgespielt, und keine davon hat mich ganz zufrieden gestellt. Endlich habe ich mir aber eine Mischung ausgedacht, die ich wirklich mag!

Es gibt zwei Schritte, einen am Anfang und einen am Ende Ihrer Erstellungsphase.

Am Anfang:

# Set the build number to the count of Git commits
if [ "${CONFIGURATION}" = "Release" ]; then
    buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

Am Ende:

# Set the build number to "DEVELOPMENT"
if [ "${CONFIGURATION}" = "Release" ]; then
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

Wenn Sie sich die Info.plist in Xcode ansehen, sehen Sie, dass die Versionsnummer "ENTWICKLUNG" lautet, die erstellte App jedoch eine ständig steigende Erstellungsnummer hat. (Solange Sie Ihre Builds immer aus demselben Zweig erstellen.)

Durch Zurücksetzen der Versionsnummer auf eine konstante Zeichenfolge am Ende wird verhindert, dass die Datei Info.plist durch Erstellen der App geändert wird.

Warum ich diese Methode mag:

• Einfach
• Verschmutzt nicht den Git-Versionsverlauf
• CFBundleVersion ist vollautomatisch
• Die hübsche Versionsnummer kann jederzeit geändert werden

Ich habe diesen Glist benutzt. Es funktioniert wie erwartet. https://gist.github.com/sekati/3172554 (alle Gutschriften gehen an den ursprünglichen Autor)

Skripte, die ich im Laufe der Zeit geändert habe.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Da diese Inhalte der Entwickler-Community helfen, habe ich daraus ein GitHub-Projekt gemacht. Also lasst es uns gut entwickeln. Hier ist das GitHub-Projekt: https://github.com/alokc83/Xcode-build-and-version-generator

Ich habe den Code für beide Skripte ein wenig verbessert. Anstatt unten zu verwenden, holen Sie sich das Neueste von GitHub

Für Version:

# xcode-version-bump.sh
# @desc Auto-increment the version number (only) when a project is archived for export. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Check the checkbox "Run script only when installing"
# 6. Drag the "Run Script" below "Link Binaries With Libraries"
# 7. Insure your starting version number is in SemVer format (e.g. 1.0.0)

# This splits a two-decimal version string, such as "0.45.123", allowing us to increment the third position.
VERSIONNUM=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${PROJECT_DIR}/${INFOPLIST_FILE}")
NEWSUBVERSION=`echo $VERSIONNUM | awk -F "." '{print $3}'`
NEWSUBVERSION=$(($NEWSUBVERSION + 1))
NEWVERSIONSTRING=`echo $VERSIONNUM | awk -F "." '{print $1 "." $2 ".'$NEWSUBVERSION'" }'`
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $NEWVERSIONSTRING" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Zum Bauen:

# xcode-build-bump.sh
# @desc Auto-increment the build number every time the project is run. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below into new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Ensure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

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

Dieser ganze Eintrag war sehr hilfreich. Ich habe diesen Trick verwendet, aber mein Skript als Post-Commit-Hook in GIT eingerichtet, sodass CFBundleVersion nach jedem erfolgreichen Commit inkrementiert wird. Das Hook-Skript geht in .git / hooks. Ein Protokoll bleibt im Projektverzeichnis.

Dies erfüllt mein grundlegendstes Kriterium. Ich möchte in der Lage sein, eine Version aus GIT abzurufen und den genauen Build neu zu erstellen, den ich zuvor hatte. Ein während des Erstellungsprozesses vorgenommenes Inkrement führt dies nicht aus.

Hier ist mein Skript:

#!/bin/sh
#
# post-commit
#
# This script increments the CFBundleVersion for each successful commit
#

plist="./XYZZY/XYZZY-Info.plist"
buildnum=$(/usr/libexec/Plistbuddy -c "Print CFBundleVersion" "$plist")
if [ -z "$buildnum" ]; then
    exit 1
fi
buildnumplus=$(expr $buildnum + 1)
/usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnumplus" "$plist"

echo $(date) "- Incremented CFBundleVersion to" $buildnumplus >> hookLog.txt

Ich weiß nicht, welcher Weg der beste ist, aber ich werde Apples Antwort veröffentlichen, falls jemand danach sucht ...

Laut dem Q & A-Beitrag von Apple :

Automatisieren von Versions- und Build-Nummern mit agvtool

Die Versions- und Buildnummernschlüssel geben jeweils die Marketing- und die interne Version Ihrer Anwendung an. agvtool ist ein Befehlszeilenprogramm, mit dem Sie diese Zahlen automatisch auf die nächsthöhere Zahl oder auf eine bestimmte Zahl erhöhen können.

Die Build-Nummer identifiziert eine unveröffentlichte oder freigegebene Version Ihrer Anwendung. Es wird in der Info.plist Ihrer Anwendung als CFBundleVersion(Bundle-Version) gespeichert .

Sie müssen die folgenden Schritte in Ihrem Xcode-Projekt ausführen:

1. Aktivieren Sie agvtool

Navigieren Sie zum Bereich "Build-Einstellungen" Ihres Ziels und aktualisieren Sie ihn für alle Build-Konfigurationen wie folgt:

• Stellen Sie die aktuelle Projektversion auf einen Wert Ihrer Wahl ein.

Ihre Xcode-Projektdatendatei project.pbxproj enthält eine CURRENT_PROJECT_VERSIONBuild-Einstellung (Aktuelle Projektversion), die die aktuelle Version Ihres Projekts angibt. agvtool durchsucht project.pbxproj nach CURRENT_PROJECT_VERSION. Es läuft weiter, falls CURRENT_PROJECT_VERSIONvorhanden, und hört andernfalls auf zu laufen. Sein Wert wird verwendet, um die Build-Nummer zu aktualisieren.

• Stellen Sie das Versionierungssystem auf Apple Generic ein.

Standardmäßig verwendet Xcode kein Versionsverwaltungssystem. Wenn Sie das Versionierungssystem auf Apple Generic einstellen, wird sichergestellt, dass Xcode alle von agvtool generierten Versionsinformationen in Ihr Projekt einbezieht.

2. Richten Sie Ihre Version ein und erstellen Sie Nummern

agvtool durchsucht die Info.plist Ihrer Anwendung nach Ihren Versions- und Build-Nummern. Es aktualisiert sie, wenn sie existieren, und tut sonst nichts. Stellen Sie sicher, dass die Tasten CFBundleVersion(Bundle-Version) und CFBundleShortVersionString(Bundle-Version string, short) in Ihrer Info.plist vorhanden sind (siehe Abbildung unten):

Beenden Sie Xcode und navigieren Sie in der Terminal-Anwendung zu dem Verzeichnis, in dem sich Ihre .xcodeproj-Projektdatei befindet, bevor Sie einen der folgenden Befehle ausführen. Die .xcodeproj-Projektdatei enthält project.pbxproj, das von agvtool verwendet wird. (Dies ist der Teil, den Sie in einem Skript anstelle der Befehlszeile ausführen können.)

Aktualisieren der Versionsnummer

Führen Sie aus, um die Versionsnummer auf eine bestimmte Version zu aktualisieren

xcrun agvtool new-marketing-version <your_specific_version>

Beispiel: Aktualisieren Sie die Versionsnummer auf 2.0

xcrun agvtool new-marketing-version 2.0

Build-Nummer aktualisieren

Führen Sie aus, um Ihre Build-Nummer automatisch zu erhöhen

xcrun agvtool next-version -all

Führen Sie aus, um die Build-Nummer Ihrer Anwendung auf eine bestimmte Version festzulegen

xcrun agvtool new-version -all <your_specific_version>

Beispiel: Setzen Sie die Build-Nummer auf 2.6.9

xcrun agvtool new-version -all 2.6.9

Bonus:

Führen Sie die aktuelle Versionsnummer aus, um sie anzuzeigen

xcrun agvtool what-marketing-version

Führen Sie aus, um die aktuelle Build-Nummer anzuzeigen

xcrun agvtool what-version

FWIW - Dies ist das, was ich derzeit verwende, um die Build-Nummer nur für Release-Builds (einschließlich Archivierung) zu erhöhen . Funktioniert gut unter Xcode 5.1.

Kopieren Sie einfach das Snippet und fügen Sie es direkt in Xcode in eine Phase zum Erstellen von Skripten ein:

buildnum=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$PRODUCT_SETTINGS_PATH")

if [ "$CONFIGURATION" = "Release" ]; then
buildnum=$((buildnum + 1))
echo "Build number updated to $buildnum"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildnum" "$PRODUCT_SETTINGS_PATH"
fi;

Danke für das Skript. Es funktioniert großartig.

Meine Info.plist befindet sich in einem Unterverzeichnis mit einem Namen, der Leerzeichen enthält. Daher musste ich das Run Script mit Anführungszeichen um den Plist-Pfad ändern:

${PROJECT_DIR}/tools/bump_build_number.sh "${PROJECT_DIR}/${INFOPLIST_FILE}"

und das Shell-Skript auf die gleiche Weise mit Anführungszeichen um alle Pfade:

#!/bin/sh

if [ $# -ne 1 ]; then
    echo usage: $0 plist-file
    exit 1
fi

plist=$1
dir=$(dirname "$plist")

# Only increment the build number if source files have changed
if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
    buildnum=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$plist")
    if [ -z "$buildnum" ]; then
        echo "No build number in $plist"
        exit 2
    fi
    buildnum=$(expr $buildnum + 1)
    /usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnum" "$plist"
    echo "Incremented build number to $buildnum"
else
    echo "Not incrementing build number as source files have not changed"
fi

Das Skript, das ich derzeit verwende, basiert stark auf dem oben genannten von Alix . Meine Anpassung unten fügt eine Überprüfung hinzu, um nur das automatische Inkrementieren eines Release- / Archiv-Builds durchzuführen.

Ohne diese Änderung kommt es zu Versionskontrollkonflikten, da jeder Entwickler die Build-Nummer mit seiner eigenen Rate erhöht. Und die Tatsache, dass der Git-Verlauf unnötig verschmutzt würde, wenn sich die Build-Nummer ständig ändert.

# xcode-build-bump.sh
# @desc Auto-increment Xcode target build number every time the project is archived
# @src stackoverflow.com/a/15483906
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Insure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

if [ "Release" != "${CONFIGURATION}" ]
then
    exit 0
fi

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

Es ist auch als GitHub-Gist verfügbar (in einem etwas einfacher zu kopierenden und einfügen) .

Ich würde die Verwendung von Autorevision empfehlen .

Xcode ermöglicht es einer Header-Datei (die zur Erstellungszeit automatisch generiert werden kann und nicht in der vcs selbst), Werte bereitzustellen, die zur Erstellungszeit in der info.plist erweitert werden. Eine exemplarische Vorgehensweise zum Einrichten finden Sie auf der Autorevision-Website .

Autorevision verfügt über einen Ausgabetyp, der auf diese Headerdateien ausgerichtet ist, um genau in diesen Situationen zu helfen.

Ein Problem bei einigen dieser Lösungen besteht darin, dass Launch Services in der Bundle-Version nur vier fünf Hauptziffern erkennt . Ich habe ein Projekt mit einer Build-Nummer, die in Tausenden liegt, deshalb wollte ich einige der weniger bedeutenden Ziffern verwenden.

Dieses Perl-Skript erhöht alle Info.plists im Projekt, nicht nur die für das aktuelle Ziel, sodass die Build-Nummern alle im Gleichschritt bleiben. Es werden auch eine Patch-Ziffer und zwei Nebenziffern verwendet, sodass Build 1234 die Version 1.23.4 erhält. Ich verwende es als Pre-Build-Verhalten, daher gilt es für alle Projekte, die ich erstelle.

Das Skript ist ziemlich brutal, aber es funktioniert für mich.

#!/usr/bin/perl

use strict;
use warnings;
use v5.12.0;

use Dir::Iterate;

for my $plist_file(grepdir { /-Info.plist$/ } '.') {
    my $build = `/usr/libexec/PlistBuddy -c "Print CFBundleVersion" '$plist_file'`;
    chomp $build;

    next unless $build;

    # Strip dots
    $build =~ s/\.//g;
    $build =~ s/^0//g;

    # Increment
    $build++;

    # Re-insert dots
    $build =~ s/^(\d{0,4}?) (\d{0,2}?) (\d{0,1}?)$/$1.$2.$3/x;

    # Insert zeroes
    $build =~ s{(^|\.)\.}{${1}0.}g;

    system qq(/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build" '$plist_file');
}

Sie können die generische Versionierung von Apple verwenden . Grundsätzlich müssen Sie nur agvtool next-version -allaus dem Verzeichnis aufrufen, in dem sich Ihre .xcproj-Datei befindet. Weitere Informationen finden Sie in der obigen URL.

Aufbauend auf der Lösung von Wil Gieseler hatte ich nur eine Änderung, die ich vornehmen wollte. Seine Lösung setzt die Anzahl der Git-Commits in die Build-Nummer ein. Nützlich, aber immer noch eine Art Schmerz, um das tatsächliche Commit zu finden, das diesen Build erstellt hat. Es war mir egal, ob die Build-Nummer monoton anstieg, und so ließ ich diese Anforderung fallen, damit ich leichter auf das Commit zugreifen konnte, das eine bestimmte Binärdatei generiert hat.

Zu diesem Zweck habe ich sein erstes Skript wie folgt geändert:

# Set the build number to the decimal conversion of the short version of the current git SHA

# Get the short version of the current git SHA in hexadecimal
SHA=$(git rev-parse --short @)
# Uppercase any alphabetic chars in SHA (bc doesn't like lowercase hex numbers)
UPPERCASE_SHA=$(tr '[:lower:]' '[:upper:]' <<< "$SHA")
# Use bc to convert the uppercase SHA from hex to decimal
BUILD_NUM=$(bc <<< "ibase=16;obase=A;$UPPERCASE_SHA")
# Set our build number to that
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUM" "${PROJECT_DIR}/${INFOPLIST_FILE}"

# To convert a build number back to a usable git SHA, run the following, substituting the build number for <build number>
# bc <<< "ibase=10;obase=16;<build number>"

Dadurch wird die Kurzversion des aktuellen Git-SHA in eine Dezimalzahl konvertiert. Hexadezimale Zeichen passen nicht gut zu Apples Build-Nummer-Anforderungen, weshalb ich dies tun musste. Um es zurück zu konvertieren, führen Sie einfach Folgendes aus:

SHA=$(bc <<< "ibase=10;obase=16;<build number>")

In Bash, wo <build number>ist die Build-Nummer, die Sie von einer Binärdatei erhalten haben? Dann renn einfach git checkout $SHAlos und los geht's.

Da dies eine Anpassung der oben erwähnten Lösung von Wil Gieseler ist , benötigen Sie auch das folgende Post-Build-Skript:

# Set the build number to "DEVELOPMENT"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Das hält deine Git-Geschichte sauber.

Ich habe das geänderte Verfahren ausprobiert und es hat nicht funktioniert, weil: -

1. Xcode 4.2.1 ändert das Unterverzeichnis xcuserdata in .xcodeproj

2. git merkt sich die vorherige Änderung in Project-Info.plist

Die folgende Änderung bewirkt, dass diese ignoriert werden und nur echte Änderungen kennzeichnen: -

if [ -n "$(find $dir \! -path "*xcuserdata*" \! -path "*.git" -newer $plist)" ]; then

Möglicherweise möchten Sie dies nur tun, wenn Sie archivieren (und beispielsweise auf TF hochladen). Andernfalls kann Ihre Versionsnummer sehr schnell steigen.

Im Schema (Produkt / Schema bearbeiten / Archivieren / Voraktionen) können Sie ein Skript hinzufügen, das nur ausgeführt wird, wenn Sie archivieren.

Außerdem möchten Sie möglicherweise die Build-Nummer jedes Mal zurücksetzen, wenn Sie die App-Version erhöhen.

Wenn Sie stattdessen das Archiv verwenden, können Sie Folgendes sicher deaktivieren:

# if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
...
# else
    # echo "Not incrementing build number as source files have not changed"
# fi

Da die Build-Nummer nur erhöht wird, wenn Sie archivieren ...

BEARBEITEN: Korrigieren Sie das, was ich gesagt habe. Voraktionen im Archiv werden nach dem Erstellen (aber vor dem Archivieren) ausgeführt, sodass die Build-Nummer für das nächste Archiv erhöht wird. Sie können jedoch ein neues Schema erstellen und diese Aktion im Build hinzufügen (vor dem Archivieren). Aktionen) Abschnitt dieses neuen Schemas. und verwenden Sie dieses Schema, wenn Sie einen neuen Build erstellen möchten

Ich verwende die letzte SVN-Revision für die Build-Nummer. Wenn Sie die Info.plist im Build-Verzeichnis ändern, hat dies keine Auswirkungen auf die Quell-Info.plist:

# use the last SVN revision as the build number:
Info_plist="$BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/Info.plist"
defaults write "${Info_plist}" CFBundleVersion `svn stat -u | awk '/'"Status against revision:"'/ {print $4}'`

Ich habe das Gefühl, meinen Stamm gefunden zu haben. Tribe, ich hoffe du bist amüsiert von VersionX.

Vor einem Jahrzehnt habe ich bei der Arbeit an einem Arbeitsbereich mit über 25 Xcode-Projekten die Gelegenheit genutzt, die Version zu automatisieren und Zeichenfolgenaktualisierungen in einem Ausmaß zu erstellen, das absurd erscheint, wenn Sie nur ein oder zwei Projekte mit gelegentlichen Aktualisierungen verwalten.

VersionX:

• kennt den Build-Typ (Release / Debug)
• sammelt Informationen zur Erstellungszeit aus dem Repository (Git-Unterstützung eingeschlossen, kann aber für hg, svn oder was auch immer Sie verwenden angepasst werden)
• Es wurden leicht anpassbare, ausgefallene Marketing-Versionszeichenfolgen bereitgestellt (die viel mehr Variationen aufwiesen, bevor der App Store eine Konvention auferlegte), sodass Sie Zeichenfolgen, die Symbole für eine "Beta" enthielten, beispielsweise mithilfe einer Git-Tag-Konvention automatisch inkrementieren konnten.
• Enthält eine Klasse mit Instanzvariablen, die Versions- und Festschreibungsinformationen enthalten. Dies ist nützlich, um Ihr About-Panel zu füllen und Protokollzeichenfolgen, Absturzberichte oder Benutzer-E-Mail-Fehlerberichte mit vorab ausgefüllten Informationen zu erstellen.

Es hat Spaß gemacht zu machen. Ich habe eine Schiffsladung über das Xcode-Build-System gelernt.

Hier ist ein Beispiel für die Art der ausgefallenen Versions- und Build-Zeichenfolgen, die VersionX automatisch generieren könnte.

VersionX 1.0.1 β7 (c5959a3 “Clean”)

Marketing-Version: VersionX 1.0.1 β7 Die "1.0.1" wird aus dem Tag für das Commit abgeleitet, während die "Beta 7" automatisch durch die Anzahl der Commits oder Builds (zum Beispiel) generiert wird.

Build-Version: (c5959a3 „Clean“) Zeigt den kurzen Commit-Hash an und informiert Sie darüber, dass im Build-Verzeichnis keine nicht festgeschriebenen Änderungen vorgenommen wurden.

VersionX (Quelle bei GitHub) - ein Barocksystem zum automatischen Inkrementieren der Version und zum Erstellen von Zeichenfolgen in Xcode-Projekten.

Die VersionX-Dokumentation.

Vielleicht möchten Sie ein neues Tool namens Xcodebump ausprobieren, das ich entwickelt habe. Es kann sowohl CFBundleShortVersionString als auch CFBundleVersion aktualisieren. Als letzter Schritt wird auch eingecheckt, um das Commit zu gitieren und zu markieren, damit es mit diesen CFBundle-Werten übereinstimmt.

Das Xcodebump-Projekt befindet sich hier:

https://github.com/markeissler/Xcodebump

Ich aktualisiere build numbermit folgender Methode.

$INFO_FILEist der Pfad der Plist-Datei. Und $build_numberist eine neue Build-Nummer für dieses Gebäude.

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build_number" "${INFO_FILE}"

Im Allgemeinen besteht meine $build_numberaus majorund minorTeile. Das minorkommt aus Projektinformationen. Also beschreibe ich, wie das majorTeil generiert wird .

## Composed by `major` and `minor`. 
## `minor` is parsed from project information. It's another story.
## Examples: `21.1`, or `21.1.3`
build_number="${major_number}.${minor_number}"

Ich habe 2 Strategien, um die zu entscheiden $build_number.

Erste Strategie

Diese Strategie verwendet die git tagAnzahl, um die majorvon zu entscheiden build number. Wenn es 53Tags des Projekts gibt, wird es 53durch Befolgen des Shell-Skripts zurückgegeben.

Im Allgemeinen nimmt es zu. Und es wird den Entwickler zwingen, vor der Veröffentlichung ein Git-Tag zu setzen.

major_number=$(git tag -l | wc -l | grep -oE "\d+")

Zweite Strategie

Lassen Sie das Jenkins CI-System über das majorTeil entscheiden . Es hat eine Umgebungsvariable BUILD_NUMBER. Sie erhöht sich automatisch, wenn sie auf dem CI-System aufbaut. Diese Informationen sind nützlich, um den Projektverlauf auf dem CI-System zu verfolgen.

major_number=${BUILD_NUMBER}

Hier ist eine aktualisierte Version. Dies funktioniert ab Xcode 9.3.1, iOS 11.

Klicken Sie in Ihrem Anwendungsziel auf "Phasen erstellen", klicken Sie auf das Symbol +, um ein neues Ausführungsskript hinzuzufügen, und fügen Sie diesen Code in das Feld ein.

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

Gehen Sie in die Datei Info.plist und setzen Sie die 'Bundle-Version' auf 1, und die 'Bundle-Versionszeichenfolge, kurz' auf 1, sollten Sie gesetzt sein.

Erstellen Sie das Projekt mit der Ansicht Info.plist, und Sie sollten sehen, dass sich die Bundle-Version (Build-Nummer) ändert.

• Beachten Sie, dass Sie ab Xcode 9.3.1 diese Änderungen nicht mehr auf der Registerkarte "Allgemein" sehen können, sondern die Änderungen beim Archivieren eines Builds und in Info.plist

Hier ist meine Lösung. Wenn Sie wie ich sind: terminalfreundlich, wie Ruby, wie semantische Versionierung, versuchen Sie dies.

Erstellen Sie eine Datei mit dem Namen Rakefile:

require "xcodeproj"
require "versionomy"

XCODEPROJECT = "MyProject.xcodeproj"
INFOPLISTFILE = "MyProject/MyProject-Info.plist"

$UPDATES = [:major,:minor,:tiny]
$UPDATES.each { |part|
  desc "increment #{part} part of version"
  task "increment:#{part}" do |task|
    version=`/usr/libexec/Plistbuddy -c "Print CFBundleVersion" #{INFOPLISTFILE}`.chomp
    version=Versionomy.parse(version)
    version=version.bump(part)

    # I use the same string for CFBundleVersion and CFBundleShortVersionString for now
    `/usr/libexec/PlistBuddy -c "Set :CFBundleVersion #{version}" #{INFOPLISTFILE}`
    `/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString #{version}" #{INFOPLISTFILE}`
    print "version upgraded to #{version}\n"
  end
}

Bereiten: gem install xcodeproj versionomy

Ausführen: rake increment:majoroder rake increment:minoroder rake increment:tinywann immer Sie möchten.

Ich finde es am bequemsten, Versionsautomatisierung und Build-Nummern mit agvtool zu verwenden .

Versuche dies:

1. Konfigurieren Sie es wie in der oben verlinkten Apple-Dokumentation beschrieben.
2. Hinzufügen eines Skripts als Voraktion zu Projekt -> Schema bearbeiten ... -> Archivieren (oder einem anderen, wenn Sie dies bevorzugen)
3. Set: Geben Sie die Build-Einstellungen von ein <your_app_target>

Das Skript (erste Zeile ist optional):

exec > ${PROJECT_DIR}/prebuild.log 2>&1
cd ${PROJECT_DIR}
xcrun agvtool next-version -all
cd -

Lassen Sie uns dies auf Apples eigene Weise tun. Es erhöht die Build-Nummer nach jedem erfolgreichen Build

Ich werde Sie durch 5 Bilder führen, gehen Sie es einfach durch.

1. Wählen Sie in der Dropdown-Liste "Schema bearbeiten ..." aus, wenn Sie Ihren Projektnamen rechts neben der Schaltfläche "Stop_build_button" auswählen. Überprüfen Sie den ersten Schritt

2. Erweitern Sie im Menü leftSide die Option 'Build' und wählen Sie 'Post-Actions'. Überprüfen Sie den zweiten Schritt

3. Hier können Sie die gewünschten Codes (Skripte) hinzufügen, die Sie nach erfolgreicher Erstellung Ihres Programms ausführen möchten. Hier müssen wir ein wenig Code hinzufügen, damit unsere Automatisierung perfekt funktioniert. >> 1. Klicken Sie in der linken Ecke auf die Schaltfläche 'Hinzufügen (+)', um eine neue Skriptdatei hinzuzufügen. >> 2. Wählen Sie nun in der Dropdown-Liste die Option 'Neue Skriptaktion ausführen'. Überprüfen Sie den dritten Schritt

4. Es hat 3 Felder >> 1. Shell ist bereits für Sie zugewiesen >> 2. Jetzt für 'Bereitstellen von Build-Einstellungen von' Wählen Sie Ihren Projektnamen. >> 3. Es gibt ein großes Feld zum Hinzufügen Ihres Skripts. Kopieren Sie einfach diesen Code und fügen Sie ihn dort ein: Überprüfen Sie den vierten Schritt

   PLIST = "$ {PROJECT_DIR} / $ {INFOPLIST_FILE}" PLB = / usr / libexec / PlistBuddy LAST_NUMBER = $ ($ PLB -c "CFBundleVersion drucken" "$ PLIST") NEW_VERSION = $ (($ LAST_NUMBER + 1)) $ PLB -c "Set: CFBundleVersion $ NEW_VERSION" "$ PLIST"

5. Nachdem Sie den 4. Schritt abgeschlossen haben, wählen Sie einfach "Schließen", um das Fenster zu schließen. Wir müssen den letzten Schritt ausführen. Gehen Sie zu Ihrer "plist.info" -Datei im Menü "Projektdatei" und stellen Sie sicher, dass der Schlüssel "Bundle-Version" im Abschnitt "Schlüssel" enthalten ist a Numeric Value Check Fünfter Schritt