Build Nummer

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Build Nummer

    Hallo Forum,

    für manche scheint diese Frage wahrscheinlich echt blöd (darum bitte ich direkt um nicht so gehässige Antworten):
    Was ist die richtige Nummer bzw. Reihenfolge für die Builds vielleicht auch verglichen mit der Versionsnummer des Programms?

    Ich habe im Web nur Sachen gefunden wie ich die Nummer eintrage etc. Bei mir ist die Build Nummer immer gleich der Versionsnummer z.B. V 1.2 (1.2).

    Liebe Grüße Kai 8|
  • Ich mache das basierend auf der Anzahl der git-commits und lasse es mit einem build script in die plist eintragen:

    Shell-Script

    1. #
    2. # Set the build number to the current git commit count.
    3. # If we're using the Dev scheme, then we'll suffix the build
    4. # number with the current branch name, to make collisions
    5. # far less likely across feature branches.
    6. # Based on: http://w3facility.info/question/how-do-i-force-xcode-to-rebuild-the-info-plist-file-in-my-project-every-time-i-build-the-project/
    7. #
    8. plist="${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    9. git=`sh /etc/profile; which git`
    10. appBuild=`"$git" rev-list --count HEAD`
    11. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $appBuild" "$plist"
    12. echo "Updated $plist"
    Alles anzeigen
    Hab ich mal bei Stackoverflow gefunden, siehe Link im comment

    Gruß, Markus
  • Hallo,

    Ich habe im Web nur Sachen gefunden wie ich die Nummer eintrage etc. Bei mir ist die Build Nummer immer gleich der Versionsnummer z.B. V 1.2 (1.2).
    Das ist aus meiner Sicht definitiv falsch ;)

    Den Quark hatte auch Apple mal geschürt und dadrüber habe ich ordentlich diskutiert.
    Im Xcode wurde bei bei den iOS-Templates sehr lange die Build Number und die Version Number mit 1.0 angegeben.
    Dabei muss es bei der Build Number einfach nur 1 sein.
    Nach viel hin und her wurde sich dann doch geeinigt, dass die Build Number doch etwas anderes sei, als die Version Number.
    Zumal es bei den OS X-Templates immer korrekt war. Seit Xcode 6.x haben sie es dann auch endlich korrigiert und bieten es richtig an.

    Ansonsten füge ich bei einem neuen Projekt auch wie Markus ein Skript-Schritt hinzu, aller Dings für jeden Build:

    Shell-Script: Increment Build Number

    1. infoPlist="${INFOPLIST_FILE}"
    2. bundleVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$infoPlist")
    3. bundleVersion=$(($bundleVersion + 1))
    4. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" "$infoPlist"
    Aus meiner Sicht ist halt die Build Number wirklich der Zähler, wie oft ich halt auf "Baue" drücke.

    Die Versionsnummer ist meines Erachtens auch kein eindeutiger Indiz für "welche Version ist das".
    Ich hatte es in der Vergangenheit schon mehrfach, dass ich eine kleine Korrektur im Code vorgenommen habe und die Version dann unter der gleiche Versionsnummer angeboten habe.
    Ist ja auch logisch um sich selbst Support zu ersparen und Anwender nicht zu verunsichern, wenn man nur wegen Kleinigkeiten von 1.2 auf 1.3 zählt.
    Das ist aus meiner Sicht nicht der Sinn der Versisnsnummer, sondern eben der Build Number.

    Viele Grüße
  • little_pixel schrieb:

    Hallo,

    Ich habe im Web nur Sachen gefunden wie ich die Nummer eintrage etc. Bei mir ist die Build Nummer immer gleich der Versionsnummer z.B. V 1.2 (1.2).
    Das ist aus meiner Sicht definitiv falsch ;)
    Den Quark hatte auch Apple mal geschürt und dadrüber habe ich ordentlich diskutiert.
    Im Xcode wurde bei bei den iOS-Templates sehr lange die Build Number und die Version Number mit 1.0 angegeben.
    Dabei muss es bei der Build Number einfach nur 1 sein.
    Nach viel hin und her wurde sich dann doch geeinigt, dass die Build Number doch etwas anderes sei, als die Version Number.
    Zumal es bei den OS X-Templates immer korrekt war. Seit Xcode 6.x haben sie es dann auch endlich korrigiert und bieten es richtig an.

    Ansonsten füge ich bei einem neuen Projekt auch wie Markus ein Skript-Schritt hinzu, aller Dings für jeden Build:

    Shell-Script: Increment Build Number

    1. infoPlist="${INFOPLIST_FILE}"
    2. bundleVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$infoPlist")
    3. bundleVersion=$(($bundleVersion + 1))
    4. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" "$infoPlist"
    Aus meiner Sicht ist halt die Build Number wirklich der Zähler, wie oft ich halt auf "Baue" drücke.

    Die Versionsnummer ist meines Erachtens auch kein eindeutiger Indiz für "welche Version ist das".
    Ich hatte es in der Vergangenheit schon mehrfach, dass ich eine kleine Korrektur im Code vorgenommen habe und die Version dann unter der gleiche Versionsnummer angeboten habe.
    Ist ja auch logisch um sich selbst Support zu ersparen und Anwender nicht zu verunsichern, wenn man nur wegen Kleinigkeiten von 1.2 auf 1.3 zählt.
    Das ist aus meiner Sicht nicht der Sinn der Versisnsnummer, sondern eben der Build Number.

    Viele Grüße
    ich verwende das so:

    versionsnummer: 2.1
    buildnummer: 12345 (svn revision)

    der user sieht dann im aboutpanel: 2.1 (12345)

    wenn mir dann jemand sagt dass es mit der version ein problem gibt (es gibt ja jede menge alpha, beta und rc-builds) dann weiß ich sofort welche gemeint ist und kann eventuell auch das komplette projekt genau so auschecken wie es kompiliert wurde (extrem praktisch zum debuggen).
  • M.M.n. sollte die Build# nicht jedes Mal geändert werden, wenn ich auf build drücke, sondern nur wenn es tatsächlich Änderungen gibt. Durch die Anzahl der commits findet man das dann auch leicht, wenn man einen bugreport bekommt. Zur Sicherheit kann man ja noch den sha-tag des commits mit reinpacken. Solange man nur Änderungen an der working copy macht, sind das für mich noch keine neuen builds, sondern erst das, was der CI-Bot nach einem commit ausspuckt.
  • gritsch schrieb:



    versionsnummer: 2.1
    buildnummer: 12345 (svn revision)

    der user sieht dann im aboutpanel: 2.1 (12345)

    wenn mir dann jemand sagt dass es mit der version ein problem gibt (es gibt ja jede menge alpha, beta und rc-builds) dann weiß ich sofort welche gemeint ist und kann eventuell auch das komplette projekt genau so auschecken wie es kompiliert wurde (extrem praktisch zum debuggen).
    Yep, das macht/gibt Sinn…

    Aber eben wie vom TE geschrieben (und Apple damals vorgegeben), dass Build Number und Versionsnummer identisch sind ist für mich unzweckmäßig.

    Viele Grüße
  • Markus Müller schrieb:

    M.M.n. sollte die Build# nicht jedes Mal geändert werden, wenn ich auf build drücke, sondern nur wenn es tatsächlich Änderungen gibt. Durch die Anzahl der commits findet man das dann auch leicht, wenn man einen bugreport bekommt. Zur Sicherheit kann man ja noch den sha-tag des commits mit reinpacken. Solange man nur Änderungen an der working copy macht, sind das für mich noch keine neuen builds, sondern erst das, was der CI-Bot nach einem commit ausspuckt.
    Ich drücke ja nur auf Build, wenn ich etwas geändert habe.
    Die Release Dinger habe ich ja archiviert…

    Aber ich denke im Allgemeinen sind wir uns alle einige was Build Number und Versionsnummer ist bzw. wie sich der Sinn unterscheidet :)

    Viele Grüße
  • little_pixel schrieb:

    gritsch schrieb:

    versionsnummer: 2.1
    buildnummer: 12345 (svn revision)

    der user sieht dann im aboutpanel: 2.1 (12345)

    wenn mir dann jemand sagt dass es mit der version ein problem gibt (es gibt ja jede menge alpha, beta und rc-builds) dann weiß ich sofort welche gemeint ist und kann eventuell auch das komplette projekt genau so auschecken wie es kompiliert wurde (extrem praktisch zum debuggen).
    Yep, das macht/gibt Sinn…
    Aber eben wie vom TE geschrieben (und Apple damals vorgegeben), dass Build Number und Versionsnummer identisch sind ist für mich unzweckmäßig.

    Viele Grüße
    ja das gibt natürlich wenig sinn. zu zählen wie oft man gebuildet hat aber auch nicht wirklich weil das keine spezielle identifikation eines ganz bestimmten code-status ist.
  • little_pixel schrieb:

    Markus Müller schrieb:

    M.M.n. sollte die Build# nicht jedes Mal geändert werden, wenn ich auf build drücke, sondern nur wenn es tatsächlich Änderungen gibt. Durch die Anzahl der commits findet man das dann auch leicht, wenn man einen bugreport bekommt. Zur Sicherheit kann man ja noch den sha-tag des commits mit reinpacken. Solange man nur Änderungen an der working copy macht, sind das für mich noch keine neuen builds, sondern erst das, was der CI-Bot nach einem commit ausspuckt.
    Ich drücke ja nur auf Build, wenn ich etwas geändert habe.Die Release Dinger habe ich ja archiviert…

    Aber ich denke im Allgemeinen sind wir uns alle einige was Build Number und Versionsnummer ist bzw. wie sich der Sinn unterscheidet :)

    Viele Grüße
    Jo.
    Seit ich mir angewöhnt habe, strikt test-driven zu entwickeln, gibt es aber viel mehr Änderungen am Testcode, der sich ja aber nicht unmittelbar auf den Releasecode auswirkt, daher macht es für meinen Workflow da keinen Sinn, jedes Mal die buildnummer hochzuzählen (und ich drücke ständig cmd-u). Das passiert dann wie gesagt erst durch den commit .

    Grüße zurück, Markus