Я використовую скрипт оболонки як частину мого процесу збирання Xcode, щоб збільшити номер збірки у файлі plist , однак це робить зрив Xcode 4.2.1 часто (з помилкою щодо цілі, що не належить до проекту; я здогадуюсь зміна файлу plist певним чином заплутує Xcode).

Сценарій оболонки зробив це так, що число збірки збільшується лише agvtoolтоді, коли файл буде новішим, ніж файл plist (тому просто побудова не збільшувала значення):

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

Чи є спосіб збільшити номер збірки (у файлі plist чи деінде), який не порушує Xcode?

ОКОНЧАЛЬНА РЕДАКТА : Зараз я займаюся подібними видами матеріалів, використовуючи сценарій python, який я щойно оприлюднив на Github . Це не добре зафіксовано, але це не повинно бути складно. У якості бонусу ця репо містить також корисний сценарій для автоматичного поєднання сторонніх бібліотек у пакет програм.

Якщо я правильно розумію ваше запитання, ви хочете змінити Project-Info.plistфайл, який є частиною стандартного шаблону проекту Xcode?

Причина, яку я прошу, полягає в тому, що Project-Info.plistзазвичай знаходиться під контролем версій, а змінити її означає, що вона буде позначена як, ну, модифікована.

Якщо з вами це нормально, наступний фрагмент оновить номер збірки та позначить файл як змінений у процесі, де get_build_numberє якийсь скрипт (тобто заповнювач місця в цьому прикладі), щоб отримати (можливо, збільшений) номер збірки, який ви хочу використовувати:

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

PlistBuddy дозволяє встановити будь-яку клавішу у файлі списку, а не лише номер версії. Ви можете створити всі потрібні файли плістів і, якщо потрібно, включити їх до ресурсів. Потім їх можна прочитати з набору.

Що стосується вашої необхідності показувати версію на панелі about та інших місцях, ви також можете вивчити налаштування CFBundleGetInfoStringта CFBundleShortVersionString.

Я заплутався з великою кількістю відповідей на це питання, і жодна з них мене не влаштовувала. Однак я нарешті придумала суміш, яка мені дуже подобається!

Є два етапи, один на початку та один у кінці фаз збирання.

На початку:

# 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

В кінці:

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

Дивлячись на Info.plist в Xcode, ви побачите номер версії "РОЗВИТОК", але вбудований додаток буде постійно збільшувати кількість збірки. (До тих пір, як ви завжди займаєтеся побудовою на одній гілці.)

Якщо повернути номер версії до постійного рядка в кінці, заважає змінити файл Info.plist, побудувавши додаток.

Чому мені подобається цей метод:

• Легко
• Не забруднює історію версій Git
• CFBundleVersion повністю автоматичний
• Приблизний номер версії можна змінювати, коли я хочу

Я використав цей список. Це працює як очікувалося. https://gist.github.com/sekati/3172554 (весь кредит припадає на оригінального автора)

Сценарії, які я змінював з часом.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Оскільки ці сутності допомагають спільноті розробників, я зробив проект GitHub з цього. Тож давайте це добре розвивати. Ось проект GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Я оновив код для обох сценаріїв трохи вдосконалення. замість того, щоб використовувати нижче, захопіть останню інформацію від GitHub

Для версії:

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

Для побудови:

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

Весь цей запис був надзвичайно корисним. Я використовував цей трюк, але створив свій сценарій як гачок після завершення в GIT, тому CFBundleVersion збільшується після кожного успішного виконання. Сценарій гака йде у .git / гачки. У каталозі проекту залишається журнал.

Це відповідає моєму основному критерію. Я хочу мати змогу витягнути версію з GIT та відновити точну збірку, яку я мав раніше. Будь-який приріст, здійснений під час збирання, цього не робить.

Ось мій сценарій:

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

Я не знаю, який спосіб найкращий, але я опублікую відповідь Apple на випадок, якщо хтось її шукає ...

Відповідно до цього запиту Apple, запитання та відповіді :

Автоматизація чисел версій та збірок за допомогою agvtool

Цифрові клавіші версії та побудови відповідно визначають маркетингову та внутрішню версії вашої програми. agvtool - це інструмент командного рядка, який дозволяє автоматично збільшувати ці числа до наступного найвищого числа або до певного числа.

Номер складання ідентифікує невипущену або випущену версію вашої програми. Він зберігається у Info.plist вашої програми як CFBundleVersion(версія пакета ).

Ви повинні виконати наступні кроки у своєму проекті Xcode:

1. Увімкнути agvtool

Перейдіть до панелі "Налаштування збірки" для своєї цілі, а потім оновіть її для всіх конфігурацій збірки таким чином:

• Встановіть для поточної версії проекту значення, яке ви обрали.

Ваш файл даних проекту Xcode, project.pbxproj, включає в себе CURRENT_PROJECT_VERSIONналаштування (Поточна версія проекту), яке вказує поточну версію вашого проекту. agvtool шукає project.pbxproj для CURRENT_PROJECT_VERSION. Він продовжує працювати, якщо CURRENT_PROJECT_VERSIONіснує, і перестає працювати, інакше. Його значення використовується для оновлення номера збірки.

• Встановіть систему версій на Apple Generic.

За замовчуванням Xcode не використовує жодної системи версій. Встановлення системи версій на Apple Generic гарантує, що Xcode буде включати всю інформацію про версію, створену agvtool, у ваш проект.

2. Налаштуйте свою версію та складіть номери

agvtool здійснює пошук у Info.plist вашої програми за вашою версією та номерами збірки. Він оновлює їх, якщо вони існують і нічого не роблять, інакше. Переконайтесь, що у вашій Info.plist існують клавіші CFBundleVersion(версія версії) та CFBundleShortVersionString(рядок версій пакету, короткі), як показано на зображенні нижче:

Закрийте Xcode та перейдіть до каталогу, що містить ваш файл проекту .xcodeproj в додатку Terminal, перш ніж запустити будь-яку з наступних команд. Файл проекту .xcodeproj містить project.pbxproj, який використовується agvtool. (Це частина, яку можна запустити в сценарії замість командного рядка.)

Оновлення номера версії

Щоб оновити номер версії до певної версії, запустіть

xcrun agvtool new-marketing-version <your_specific_version>

Наприклад: Оновіть номер версії до 2.0

xcrun agvtool new-marketing-version 2.0

Оновлення номера збірки

Щоб автоматично збільшити номер складання, запустіть

xcrun agvtool next-version -all

Щоб встановити номер збірки програми для конкретної версії, запустіть

xcrun agvtool new-version -all <your_specific_version>

Наприклад: Встановіть номер збірки на 2.6.9

xcrun agvtool new-version -all 2.6.9

Бонус:

Щоб переглянути номер поточної версії, запустіть

xcrun agvtool what-marketing-version

Щоб переглянути поточний номер збірки, запустіть

xcrun agvtool what-version

FWIW - це те, що я зараз використовую для збільшення кількості збірки лише для версій версій (що включає архівування). Добре працює під Xcode 5.1.

Просто скопіюйте / вставте фрагмент у фазу збірки сценарію Run безпосередньо в 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;

Дякую за сценарій Це чудово працює.

Мій Info.plist знаходиться у підкаталозі з іменем, що містить пробіли, тому мені довелося змінити Запуск сценарію цитатами навколо шляху до списку:

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

і сценарій оболонки аналогічно з цитатами по всіх шляхах:

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

Сценарій, який я зараз використовую, в значній мірі заснований на Алікс вище. Моя адаптація, нижче, додає чек, щоб зробити автоматичне збільшення лише для випуску / складання архіву.

Без цієї зміни виникнуть конфлікти щодо контролю версій, оскільки кожен розробник збільшуватиме кількість збірки за власною швидкістю. І той факт, що історія git була б непотрібно забруднена, коли число збірки постійно змінюється.

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

Він також доступний (дещо простіше скопіювати та вставити формат) у вигляді суті GitHub .

Я б рекомендував використовувати авторевізію .

Xcode дозволяє файлу заголовка (який може бути автоматично сформований під час збирання, а не в vcs його самому), надавати значення, які будуть розгорнуті в info.plist під час збирання. Ви можете ознайомитись із покроковою інструкцією щодо налаштування цієї програми на веб-сайті для автоматичного перегляду .

Авторевізія має вихідний тип, орієнтований на файли заголовків цих типів, щоб допомогти саме в таких ситуаціях.

Одне з питань цих рішень полягає в тому, що Launch Services розпізнає лише чотири п'ять основних цифр у версії пакету . У мене є проект з номером збірки, який налічує тисячі, тому я хотів використати деякі менш значущі цифри.

Цей сценарій Perl збільшує всі Info.plists у проекті, а не лише один для поточної цілі, тому номери збирання залишаються в режимі блокування. Він також використовує одну патч-цифру та дві незначні цифри, тому для складання 1234 надається версія 1.23.4. Я використовую це як поведінку перед побудовою, тому це стосується всіх проектів, які я будую.

Сценарій досить жорстокий, але він працює для мене.

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

Ви можете використовувати загальну версію Apple . В основному все, що вам потрібно зробити, - це зателефонувати agvtool next-version -allз каталогу, який розміщує ваш файл .xcproj. Для отримання більш детальної інформації ознайомтеся з URL-адресою вище.

Спираючись на рішення Віла Гізелера , я хотів зробити лише одну зміну. Його рішення позначає кількість git комісій в число збірки. Корисний, але все-таки біль болючість знайти фактичну поступку, яка створила цю конструкцію. Мене не надто хвилювало, чи збільшилось число збірки монотонно, і тому я відмовився від цієї вимоги, щоб я міг легше отримати доступ до комітету, що генерував заданий бінарний файл.

З цією метою я змінив його перший сценарій на такий:

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

Це перетворює коротку версію поточного git SHA в десяткову. Шістнадцяткові символи не дуже добре грають із вимогами Apple щодо кількості збірок, тому мені довелося це зробити. Щоб перетворити його назад, просто запустіть щось подібне:

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

у баші, де <build number>номер збірки, який ви отримали з двійкового файлу. Потім просто біжіть git checkout $SHA, і там ви йдете.

Оскільки це адаптація рішення Віла Гізелера , як згадувалося вище, вам також знадобиться наступний сценарій після складання:

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

що зберігає вашу історію git чистою.

Я спробував модифіковану процедуру, і вона не вийшла, тому що: -

1. Xcode 4.2.1 змінює підкаталог xcuserdata в .xcodeproj

2. git відзначає попередню зміну в Project-Info.plist

Наступна модифікація призводить до того, що вони будуть ігноровані та позначають лише справжні зміни: -

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

Ви можете зробити це лише під час архівації (наприклад, завантаження в TF). Інакше номер вашої версії може зрости дуже швидко.

У схему (Продукт / Редагувати схему / Архів / Попередні дії) ви можете додати скрипт, який буде виконуватися лише при архіві.

Крім того, ви можете скинути номер збірки кожен раз, коли збільшуєте версію програми.

Останнє, якщо ви замість цього використовуєте архів, ви можете спокійно відключити:

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

Оскільки кількість збірки збільшуватиметься лише при архіві ...

EDIT: Виправте те, що я сказав, попередні дії в архіві відбудуться після збирання (але перед архівуванням), тому число збірки буде збільшенням для наступного архіву ... Але ви можете створити нову схему і додати цю дію в збірку (попередньо- дії) розділ цієї нової схеми. і використовуйте цю схему, коли ви хочете створити нову збірку

Я використовую останню версію SVN для номера збірки. Якщо ви зміните Info.plist у каталозі збірки, ви не вплинете на джерело 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}'`

Я відчуваю, що знайшов своє плем'я. Племін, я сподіваюся, що вас розважає VersionX.

Десять років тому під час роботи над робочою областю, в якій було понад 25 проектів Xcode, я скористався можливістю автоматизувати версію та будувати оновлення рядків до такої міри, яка може здатися абсурдною, якщо ви підтримуєте лише проект чи два з періодичними оновленнями.

ВерсіяX:

• знає тип збірки (випуск / налагодження)
• збирає інформацію під час збирання із сховища (включена підтримка git, але може бути налаштована під hg, svn або будь-яке інше, що ви використовуєте)
• передбачено легко настроювані рядки модних маркетингових версій (які мали набагато більше варіацій до того, як App Store наклав конвенцію), щоб ви могли автоматично збільшувати рядки, що включали символи для "бета", наприклад, за допомогою конвенції git tag.
• включає клас, заповнений змінними екземпляра, що містять інформацію про версії та фіксацію. Це корисно для заповнення інформації про панель та для створення рядків журналу, звітів про збої чи звітів про помилки користувачів електронною поштою із попередньо заповненою інформацією.

Це було весело робити. Я дізнався навантаження на човні про систему збирання Xcode.

Ось приклад типу фантазійних версій і рядків збірки VersionX може автоматично генеруватися.

ВерсіяX 1.0.1 β7 (c5959a3 "Очистити")

Маркетингова версія: VersionX 1.0.1 β7 "1.0.1 є похідним від тегу для комісії, тоді як" Beta 7 "автоматично генерується підрахунком комітів або числом збірок (наприклад).

Версія збірки: (c5959a3 "Очистити") Відображає хеш коротких фіксів і повідомляє вам, що в каталозі збірки було внесено нульові невідомі зміни.

VersionX (джерело в GitHub) - барокова система для автоматичного збільшення версії та побудови рядків у проектах Xcode.

Документація VersionX.

Ви можете перевірити новий інструмент, який я розробляв, під назвою Xcodebump. Він може обробляти оновлення як CFBundleShortVersionString, так і CFBundleVersion. Як завершальний крок, він також перевірить, щоб git і позначив команду, щоб відповідати цим значенням CFBundle.

Проект Xcodebump розміщений тут:

https://github.com/markeissler/Xcodebump

Я оновлюю build numberнаступним методом.

$INFO_FILE- шлях до файлу plist. І $build_numberце новий номер збірки для цієї будівлі.

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

Взагалі моє $build_numberскладено majorі minorчастинами. Подання minorвідбувається з інформації про проект. Тому я описую, як генерувати 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}"

У мене є дві стратегії для вирішення питання $build_number.

Перша стратегія

Ця стратегія використовує git tagлічильник , щоб вирішити majorз build number. Якщо є 53теги проекту, він повернеться 53, виконавши сценарій оболонки.

Взагалі, вона збільшується. І це змусить розробника поставити тег git перед публікацією.

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

Друга стратегія

Нехай система Дженкінса CI вирішує majorдеталь. Він має змінну середовища BUILD_NUMBER. Він автоматично збільшується при побудові на системі CI. Ця інформація корисна для відстеження історії проекту в системі ІС.

major_number=${BUILD_NUMBER}

Ось оновлена ​​версія. Це працює з Xcode 9.3.1, iOS 11.

Клацніть на "Створити фази" від цілі програми, натисніть значок +, щоб додати новий сценарій запуску, і у вікні вставте цей код.

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

Увійдіть у файл Info.plist і встановіть «Версія пакета» на 1, а «Рядок версій пакету, короткий» на 1, вам слід встановити.

Створіть проект за допомогою перегляду Info.plist, і вам слід побачити зміну версії пакета (номер збірки).

• Зауважте, що станом на Xcode 9.3.1 ви не зможете побачити ці зміни на загальній вкладці, але побачите зміни під час архівації збірки та в Info.plist

Ось моє рішення. Якщо ви схожі на мене: термінал, як рубін, як семантична версія, спробуйте це.

Створіть файл, названий таким, 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
}

Підготуйте: gem install xcodeproj versionomy

Run: rake increment:majorабо rake increment:minorабо rake increment:tinyвсякий раз , коли ви хочете.

Мені здається найзручнішим використовувати Автоматизацію версій та створення номерів за допомогою agvtool .

Спробуйте це:

1. Налаштуйте його, як описано в документації Apple, пов'язаній вище
2. Додайте скрипт як попередня дія до проекту -> Редагувати схему ... -> Архів (або інше, якщо вам зручніше)
3. Встановити: Надати налаштування збірки з <your_app_target>

Сценарій (перший рядок не є обов'язковим):

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

Давайте зробимо це по-своєму Apple. Це збільшить кількість збірки після кожної успішної збірки

Я проведу вас через 5 зображень, просто перегляньте його.

1. Виберіть "Змінити схему ..." зі спадного меню, коли ви виберете ім'я проекту, розташоване праворуч від кнопки Stop_build_button. Перевірте перший крок

2. У меню leftSide розгорніть опцію 'Build' та виберіть пункт 'Post-Actions' Перевірте другий крок

3. Тут ви можете додати потрібні коди (скрипти), які ви хочете виконати після успішної збірки вашої програми. Це місце, де нам потрібно додати невелику кількість коду, щоб наша автоматизація працювала ідеально. >> 1. Виберіть «Додати (+)» кнопки з LeftSide кутку , щоб додати новий файл сценарію >> 2. Тепер з меню, що випадає виберіть «New Run Action Script» Перевірка Третій крок

4. У ньому є 3 поля >> 1. оболонка вже призначена для вас >> 2. зараз у розділі "Забезпечити налаштування параметрів у" Виберіть назву проекту. >> 3. Theres велике поле , щоб додати свій скрипт, просто скопіювати і повз цього коду там: Перевірте Четвертий крок

   PLIST = "$ {PROJECT_DIR} / $ {INFOPLIST_FILE}" PLB = / usr / libexec / PlistBuddy LAST_NUMBER = $ ($ PLB -c "Друкувати CFBundleVersion" "$ PLIST") NEW_VERSION = $ (($ LAST_NUMBER + 1) $ PLB -c "Набір: CFBundleVersion $ NEW_VERSION" "$ PLIST"

5. Після завершення 4-го кроку просто виберіть "Закрити", щоб закрити вікно, і ми повинні зробити останній крок, перейдіть до свого файлу "plist.info" у меню файлу проекту та переконайтесь, що клавіша "Версія пакета" у розділі "Ключ" найбільше містить П'ятий крок перевірки числового значення