He metido la pata con muchas de las respuestas a esta pregunta, y ninguna de ellas me satisfizo del todo. Sin embargo, finalmente se me ocurrió una mezcla que realmente me gusta!

Hay dos pasos, uno al principio y otro al final de las fases de construcción.

Al principio:

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

Al final:

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

Mirando la información.plist en Xcode verá que el número de versión es "DESARROLLO", pero la aplicación construida tendrá un número de compilación en constante aumento. (Mientras como siempre haces tus construcciones de la misma rama.)

Volver a establecer el número de versión en una cadena constante al final evita la Información.plist archivo de ser cambiado mediante la construcción de la aplicación.

Por qué me gusta este método:

• Fácil
• No contamina el historial de versiones de Git
• CFBundleVersion es totalmente automática
• El número de versión pretty se puede modificar cuando quiera

He utilizado este brillo su impresionante y funciona como se esperaba. https://gist.github.com/sekati/3172554 (todo el crédito va al autor original)

Sctipts que he modificado con el tiempo.

Xcode-versionString-generator.sh ,

Xcode-build-number-generator.sh

Como estos gist están ayudando a la comunidad dev. Pensé en hacer github proyecto fuera de él. Así que vamos a desarrollarlo bien. Aquí está el github proyecto: https://github.com/alokc83/Xcode-build-and-version-generator

He actualizado el código para ambos script un poco de mejora. en lugar de usar la siguiente captura lo último de github

Para la Versión:

# 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}"

Para construir:

# 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 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)

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}"

Toda Esta entrada fue extremadamente útil. Usé este truco, pero configuré mi script como un gancho post-commit en GIT, por lo que CFBundleVersion se incrementa después de cada confirmación exitosa. El guión de gancho entra .git / hooks. Se deja un registro en el directorio del proyecto.

Esto cumple con mi criterio más básico. Quiero poder extraer una versión de GIT y reconstruir la compilación exacta que tenía anteriormente. Cualquier incremento realizado durante el proceso de compilación no hace esto.

Aquí está mi script:

#!/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

No se que camino es el mejor, pero voy a publicar la respuesta de Apple en caso de que alguien lo esté buscando...

De acuerdo con esto El post de preguntas y respuestas de Apple :

Automatización de Números de Versión y Compilación Usando agvtool

Las claves version y build number especifican respectivamente las versiones de marketing e internas de su aplicación. agvtool es una herramienta de línea de comandos que le permite aumentar automáticamente estos números al siguiente número más alto o a un número específico.

El número de compilación identifica una versión no publicada o publicada de su aplicación. Se almacena en la información de su aplicación.plist as CFBundleVersion (versión Bundle).

Debe completar los siguientes pasos en su proyecto Xcode:

1. Activar agvtool

Navegue hasta el panel Configuración de compilación de su destino, luego actualícelo para todas sus configuraciones de compilación de la siguiente manera:

• Establecer la Versión Actual del Proyecto a valor de su elección.

Su archivo de datos del proyecto Xcode, proyecto.pbxproj, incluye una configuración de compilación CURRENT_PROJECT_VERSION (Versión actual del proyecto), que especifica la versión actual de su proyecto. agvtool busca en project.pbxproj for CURRENT_PROJECT_VERSION. Continúa ejecutándose si existe CURRENT_PROJECT_VERSION y deja de ejecutarse, de lo contrario. Su valor se utiliza para actualizar el número de compilación.

• Establezca el Sistema de control de versiones en Apple Generic.

Por defecto, Xcode no usa ningún sistema de control de versiones. Configuración El sistema de control de versiones de Apple Generic garantiza que Xcode incluirá toda la información de versión generada por agvtool en su proyecto.

1. Configura tu versión y construye números

Agvtool busca la información de su aplicación.plist para su versión y construir números. Los actualiza si existen y no hace nada, de lo contrario. Asegúrese de que las teclas CFBundleVersion (Bundle version) y CFBundleShortVersionString (Bundle versions string, short) existan en su INFO.plist como se ve en la imagen de abajo:

Salga de Xcode, luego vaya al directorio que contiene su.archivo de proyecto xcodeproj en la aplicación Terminal antes de ejecutar cualquiera de los siguientes comandos. El .el archivo de proyecto xcodeproj contiene el proyecto.pbxproj, que es utilizado por agvtool. (Esta es la parte que puede ejecutar en un script en lugar de en la línea de comandos.)

Actualización del Número de versión

Para actualizar el número de versión a un número específico version, run

xcrun agvtool new-marketing-version <your_specific_version>

Ej: Actualizar el número de versión a 2.0

xcrun agvtool new-marketing-version 2.0

Actualizando el número de compilación

Para incrementar automáticamente tu número de compilación, ejecuta

xcrun agvtool next-version -all

Para establecer el número de compilación de su aplicación en una versión específica, ejecute

xcrun agvtool new-version -all <your_specific_version>

Ej: Establezca el número de compilación en 2.6.9

xcrun agvtool new-version -all 2.6.9

Bono:

Para ver el número de versión actual, ejecute

xcrun agvtool what-marketing-version

Para ver la compilación actual número, ejecutar

xcrun agvtool what-version

FWIW - esto es lo que estoy usando actualmente para aumentar el número de compilación solo para compilaciones de versiones (que incluye el archivado). Funciona bien bajo Xcode 5.1.

Simplemente copie / pegue el fragmento en una fase de compilación Run script directamente en Xcode:

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;

Gracias por el guión. Funciona muy bien.

Mi información.plist está en un subdirectorio con un nombre que contiene espacios, así que tuve que modificar el Script de ejecución con comillas alrededor de la ruta de plist:

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

Y el script de shell de la misma manera con comillas alrededor de todas las rutas:

#!/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

El script que estoy usando actualmente está basado en de Alix, arriba. Mi adaptación, a continuación, agrega una comprobación para hacer solo el auto-incremento en una compilación release / archive.

Sin ese cambio, habrá conflictos de control de versiones, ya que cada desarrollador incrementará el número de compilación a su propio ritmo. Y el hecho de que el historial de git estaría innecesariamente contaminado con el número de compilación cambiando todo el tiempo.

# 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}"

También está disponible (en un copiar y pegar formato) como un GitHub gist .

Recomendaría el uso de autorevisión.

Xcode permite que un archivo de encabezado (que se puede generar automáticamente en el momento de la compilación y no en el vcs) proporcione valores que se expandirán en la información.plist en tiempo de construcción. Puede encontrar un tutorial para configurar esto en el sitio web de autorevisión .

Autorevision tiene un tipo de salida orientado a estos tipos de archivos de encabezado para ayudar exactamente en estas situaciones.

Un problema con algunas de estas soluciones es que Launch Services solo reconoce cuatro cinco dígitos principales en la versión del paquete. Tengo un proyecto con un número de construcción que está en los miles, así que quería utilizar algunos de los dígitos menos significativos.

Este script de Perl incrementa toda la información.plists en el proyecto, no solo el del objetivo actual, por lo que los números de compilación se mantienen al mismo paso. También utiliza un dígito de parche y dos dígitos menores, por lo que se da la compilación 1234 versión 1.23.4. Lo uso como un comportamiento previo a la construcción, por lo que se aplica a todos los proyectos que construyo.

El guión es bastante de fuerza bruta, pero funciona para mí.

#!/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');
}

Puedes usar El control de versiones genérico de Apple. Básicamente todo lo que tiene que hacer es llamar a agvtool next-version -all desde el directorio que aloja su .xcproj archivo. Para más detalles echa un vistazo a la url de arriba.

Basándome en la solución de Wil Gieseler, solo tenía un cambio que quería hacer. Su solución se pone el recuento de git en el número de compilación. Útil, pero aún así un poco molesto para encontrar el commit real que creó esa construcción. No me importaba demasiado si el número de compilación aumentaba monótonamente, por lo que eliminé ese requisito para poder acceder más fácilmente a la confirmación que generaba un binario dado.

Con ese fin, modifiqué su primer guión a la siguiente:

# 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>"

Esto convierte la versión corta del git SHA actual en decimal. Los caracteres hexadecimales no juegan muy bien con los requisitos de número de compilación de Apple, por lo que tuve que hacer esto. Para convertirlo de nuevo, simplemente ejecutarías algo como esto:

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

En bash, donde <build number> es el número de compilación que obtuviste de un binario. Entonces, simplemente ejecuta git checkout $SHA, y ahí lo tienes.

Debido a que esta es una adaptación de la solución de Wil Gieseler, como se mencionó anteriormente, también necesita el siguiente script post-build:

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

Que mantiene limpio tu historial de git.

Probé el procedimiento modificado y no funcionó, porque:-

1. Xcode 4.2.1 cambia el subdirectorio xcuserdata en .xcodeproj

2. Git toma nota del cambio anterior en Project-Info.plist

La siguiente modificación hace que estos sean ignorados y solo indica cambios genuinos: -

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

Es posible que desee hacer esto solo cuando archive (y cargue en TF, por ejemplo). De lo contrario su número de versión podría subir muy rápido..

En el esquema (Product / Edit Scheme / Archive / Pre-Actions) puede agregar un script que se ejecutará solo cuando archive.

Además, es posible que desee restablecer el número de compilación cada vez que incremente la versión de la aplicación.

Por último, si utiliza archive en su lugar, puede desactivar de forma segura:

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

Como la construcción el número se incrementará solo cuando archive...

EDITAR: Corrija lo que dije, las acciones previas en el archivo ocurren después de la compilación (pero antes del archivo), por lo que el número de compilación será un incremento para el siguiente archivo... Pero puede crear un nuevo esquema y agregar esta acción en la sección build (pre-actions) de este nuevo esquema. y utilice este esquema cuando desee crear una nueva compilación

Utilizo la última revisión SVN para el número de compilación. Si cambia la Información.plist en el directorio de compilación, no afectará la información de origen.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}'`

Siento que he encontrado a mi tribu. Tribu, espero que os divierta VersionX.

Hace una década, mientras trabajaba en un espacio de trabajo que tenía más de 25 proyectos Xcode en él, aproveché la oportunidad para automatizar la versión y crear actualizaciones de cadenas de texto a un grado que podría parecer absurdo, si solo mantiene un proyecto o dos con actualizaciones ocasionales.

VersionX:

• es consciente del tipo de compilación (Release / Debug)
• recopila información en el tiempo de compilación del repositorio (soporte git incluido, pero se puede personalizar para hg, svn o lo que se use)
• proporciona cadenas de versión de marketing de lujo fácilmente personalizables (que tenían mucha más variación antes de que la App Store impusiera una convención) para que pueda aumentar automáticamente las cadenas que incluyen símbolos para una "beta" utilizando una convención de etiquetas git, por ejemplo.
• incluye una clase poblada con variables de instancia que contienen información de versión y confirmación. Esto es útil para rellenar su panel acerca de y la construcción de cadenas de registro, informes de fallos o informes de errores de correo electrónico del usuario con información pre-rellenada.

Fue divertido de hacer. Aprendí un montón sobre el sistema de compilación Xcode.

Aquí hay un ejemplo del tipo de versión elegante y cadenas de compilación que VersionX podría generar automáticamente.

VersionX 1.0.1 β7 (c5959a3 "Limpio")

Versión de marketing: VersionX 1.0.1 β7 El "1.0.1 se deriva de la etiqueta para el commit, mientras La "Beta 7" es generada automáticamente por el conteo de confirmaciones, o conteo de compilación (por ejemplo).

Versión de compilación: (c5959a3 " Limpio") Muestra el hash de confirmación corta, y le informa que el directorio de compilación tenía cero cambios no confirmados.

VersionX (fuente en GitHub) - un sistema barroco para incrementar automáticamente la versión y construir cadenas en proyectos Xcode.

La Documentación de VersionX.

Es posible que desee echar un vistazo a una nueva herramienta que he estado desarrollando llamado Xcodebump. Puede manejar la actualización de CFBundleShortVersionString y CFBundleVersion. Como paso final, también verificará git y etiquetará la confirmación para que coincida con esos valores CFBundle.

El proyecto Xcodebump se encuentra aquí:

Https://github.com/markeissler/Xcodebump

Actualizo build number por el siguiente método.

$INFO_FILE es la ruta del archivo plist. Y $build_number es un nuevo número de construcción para este edificio.

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

Generalmente, mi $build_number está compuesto por major y minor partes. El minor proviene de la información del proyecto. Así que describo cómo generar la parte major.

## 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}"

Tengo 2 estrategias para decidir el $build_number.

Primera estrategia

Esta estrategia utiliza el conteo git tag para decidir el major de build number. Si hay 53 etiquetas del proyecto, devolverá 53 siguiendo el script de shell.

Generalmente, está aumentando. Y obligará al desarrollador a poner una etiqueta git antes de publicar.

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

Segunda estrategia

Dejemos que Jenkins el sistema de CI decida la parte major. Tiene una variable de entorno BUILD_NUMBER. Aumenta automáticamente cuando se basa en el sistema de CI. Esta información es útil para rastrear el historial del proyecto en el sistema de IC.

major_number=${BUILD_NUMBER}

Aquí está mi solución. Si eres como yo: terminal friendly, como ruby, como versionado semántico, prueba esto.

Crea un archivo llamado Rakefile que contenga esto:

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
}

Prepare: gem install xcodeproj versionomy

Ejecuta: rake increment:major o rake increment:minor o rake increment:tiny cuando quieras.

Aquí está una versión actualizada. Esto funciona a partir de Xcode 9.3.1, iOS 11.

Haga clic en 'Build Phases' desde el destino de su aplicación, haga clic en el icono + para agregar un nuevo script de ejecución y, en el cuadro, pegue este código.

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}"

Entra en la información.plist y establezca la 'Versión del paquete' en 1, y la 'Cadena de versiones del paquete, corto' en 1, debe establecerse.

Construye el proyecto con Info.plist a la vista, y debería ver la versión del paquete (número de compilación) cambiar.

• Nota que a partir de Xcode 9.3.1, no podrá ver estos cambios desde la pestaña general, pero verá los cambios cuando archive una compilación y en Información.plist