Ответ 1

Если я правильно понимаю ваш вопрос, вы хотите изменить файл Project-Info.plist, который является частью стандартного шаблона проекта XCode?

Я спрашиваю об этом потому, что Project-Info.plist обычно находится под контролем версий, и его изменение означает, что он будет помечен как хорошо измененный.

Если вас это устраивает, то следующий фрагмент обновит номер сборки и get_build_number файл как измененный в процессе, где get_build_number - это некоторый скрипт (т. 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 позволяет вам установить любой ключ в файле plist, а не только номер версии. Вы можете создать все необходимые файлы plist и при необходимости включить их в ресурсы. Затем их можно прочитать из комплекта.

Что касается необходимости показывать версию на панели about и в других местах, вы также можете посмотреть настройки CFBundleGetInfoString и CFBundleShortVersionString.

Ответ 2

Я столкнулся с множеством ответов на этот вопрос, и никто из них не удовлетворил меня. Тем не менее, я, наконец, придумал смесь, которая мне очень нравится!

Есть два шага: один в начале и один в конце фаз сборки.

В начале:

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

В конце:

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

Глядя на Info.plist в Xcode, вы увидите, что номер версии - "РАЗВИТИЕ", но встроенное приложение будет постоянно увеличивать номер сборки. (Пока вы всегда делаете свои сборки из одной ветки.)

Установка номера версии обратно в константную строку в конце предотвращает изменение файла Info.plist путем создания приложения.

Почему мне нравится этот метод:

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

Ответ 3

Я использовал этот блеск, его удивительный и работает так, как ожидалось. https://gist.github.com/sekati/3172554 (все кредиты принадлежат оригинальному автору)

Sctipts, которые я модифицировал за это время.

xcode-versionString-generator.sh,

xcode-build-number-generator.sh

Как этот принцип помогает сообществу разработчиков. Я думал, что из него выйдет проект github. Поэтому давайте развить это хорошо. Вот проект github: https://github.com/alokc83/Xcode-build-and-version-generator

Я обновил код для script немного улучшения. вместо использования ниже возьмите последнее из 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 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}"

Ответ 4

Вся эта запись была очень полезна. Я использовал этот трюк, но настроил свой script как крюк после фиксации в GIT, поэтому CFBundleVersion увеличивается после каждого успешного фиксации. Крючок script входит в .git/hooks. В каталоге проекта остается журнал.

Это соответствует моему самому основному критерию. Я хочу иметь возможность вытащить версию из GIT и перестроить точный сборник, который у меня был ранее. Любое приращение, выполняемое во время процесса сборки, не делает этого.

Вот мой 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

Ответ 5

Я не знаю, какой путь лучший, но я отправлю ответ Apple на всякий случай, если кто-то его ищет...

В соответствии с этим Apple Q & A post:

Автоматизация версий и построение чисел с помощью agvtool

Ключи версии и номера сборки соответственно определяют маркетинговые и внутренние версии вашего приложения. agvtool - это инструмент командной строки, который позволяет автоматически увеличивать эти числа до следующего наибольшего числа или определенного номера.

Номер сборки идентифицирует невыпущенную или выпущенную версию вашего приложения. Он хранится в ваших приложениях Info.plist как CFBundleVersion (версия Bundle).

Вы должны выполнить следующие шаги в своем проекте Xcode:

• Включить agvtool

Перейдите в панель "Параметры сборки" вашей цели, а затем обновите ее для всех конфигураций сборки следующим образом:

• Установите текущую версию проекта на значение по вашему выбору.

Файл данных проекта Xcode, project.pbxproj, включает параметр сборки CURRENT_PROJECT_VERSION (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 (версия Bundle) и CFBundleShortVersionString (строки, короткие), а на странице ниже:

Закройте Xcode, затем перейдите в каталог, содержащий файл проекта .xcodeproj в приложении Terminal, перед запуском любой из следующих команд. Файл проекта .xcodeproj содержит project.pbxproj, который используется agvtool. (Это часть, которую вы можете запустить в script вместо командной строки.)

Обновление номера версии

Чтобы обновить номер версии до определенной версии, запустите

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

Bonus:

Чтобы просмотреть номер текущей версии, запустите

xcrun agvtool what-marketing-version

Чтобы просмотреть текущий номер сборки, запустите

xcrun agvtool what-version

Ответ 6

FWIW - это то, что я сейчас использую, чтобы увеличить номер сборки только для релизов (включая архивирование). Работает отлично под Xcode 5.1.

Просто скопируйте/вставьте фрагмент в фазу выполнения script непосредственно в 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;

Ответ 7

Спасибо за script. Он отлично работает.

My Info.plist находится в подкаталоге с именем, содержащим пробелы, поэтому мне пришлось изменить Run Script с кавычками по пути plist:

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

и оболочку Script таким же образом с кавычками вокруг всех путей:

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

Ответ 8

script Я использую в настоящее время очень много основанных на Alix's выше. Моя адаптация, ниже, добавляет проверку только для автоматического увеличения в сборке релизов/архивов.

Без этого изменения будут конфликты с управлением версиями, так как каждый разработчик будет увеличивать номер сборки по своей ставке. И тот факт, что история 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 gist.

Ответ 9

Я бы рекомендовал использовать autorevision.

Xcode позволяет создать файл заголовка (который может быть сгенерирован автоматически во время сборки, а не сам vcs), чтобы предоставить значения, которые будут расширены в info.plist во время сборки. Вы можете найти пошаговое руководство для настройки этого параметра на веб-сайте autorevision.

Autorevision имеет тип вывода, ориентированный на файлы заголовков этих типов, чтобы помочь в этих ситуациях.

Ответ 10

Одна из проблем с некоторыми из этих решений заключается в том, что Launch Services распознает только четыре пять основных цифр в версии пакета, У меня есть проект с номером сборки, который в тысячах, поэтому я хотел использовать некоторые из менее значимых цифр.

Этот Perl script увеличивает все Info.plists в проекте, а не только на текущую цель, поэтому все номера сборки остаются в состоянии блокировки. Он также использует одну патч-цифру и две младшие цифры, поэтому для сборки 1234 предоставляется версия 1.23.4. Я использую его как поведение pre-build, поэтому он применяется ко всем проектам, которые я создаю.

script - довольно грубая сила, но он работает для меня.

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

Ответ 11

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

Ответ 12

Основываясь на решении Wil Gieseler, у меня было только одно изменение, которое я хотел сделать. Его решение помещает кол-во git в число сборки. Полезный, но все же вид боли, чтобы найти фактическую фиксацию, которая создала эту сборку. Мне было неважно, был ли номер сборки монотонно возрастающим, и поэтому я отбросил это требование, чтобы я мог более легко получить доступ к фиксации, которая сгенерировала данный двоичный файл.

С этой целью я изменил свой первый script на следующее:

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

в bash, где <build number> - номер сборки, полученный вами из двоичного файла. Затем просто запустите git checkout $SHA, и там вы идете.

Поскольку это адаптация решения Wil Gieseler, как уже упоминалось выше, вам также понадобится следующая пост-сборка script:

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

который сохраняет вашу историю git чистой.

Ответ 13

Я пробовал модифицированную процедуру, и она не работала, потому что: -

• Xcode 4.2.1 изменяет подкаталог xcuserdata в .xcodeproj

• git отмечает предыдущее изменение в Project-Info.plist

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

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

Ответ 14

Возможно, вы захотите сделать это, только когда архив (и, например, загрузите в TF). В противном случае ваш номер версии может стать очень быстрым.

В схеме (Product/Edit Scheme/Archive/Pre-Actions) вы можете добавить script, который будет выполнен только при архивировании.

Кроме того, вы можете захотеть reset номер сборки каждый раз, когда вы увеличиваете версию приложения.

Последнее, если вы используете архив вместо этого, вы можете безопасно отключить:

# 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: Исправьте, что я сказал, предварительные действия в архиве происходят после сборки (но до архивации), поэтому номер сборки будет увеличиваться для следующего архива... Но вы можете создать новую схему и добавить это действие в сборку (предварительные действия) этой новой схемы. и используйте эту схему, когда вы хотите создать новую сборку

Ответ 15

Я использую последнюю версию 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}'`

Ответ 16

Я чувствую, что нашел свое племя. Племя, надеюсь, тебя позабавила версия X.

Десять лет назад, работая над рабочим пространством, в котором было более 25 проектов XCode, я воспользовался возможностью автоматизировать версию и создавать обновления строк до такой степени, которая может показаться абсурдной, если вы поддерживаете только один или два проекта со случайными обновлениями.

VersionX:

• знает о типе сборки (Release/Debug)
• собирает информацию во время сборки из репозитория (включая поддержку git, но может быть настроен для hg, svn или любого другого используемого вами)
• предоставил легко настраиваемые строки причудливой маркетинговой версии (которые имели гораздо больше вариаций, прежде чем App Store наложил соглашение), чтобы вы могли автоматически увеличивать строки, которые включали символы для "беты", например, с использованием соглашения git-тегов.
• включает в себя класс, заполненный переменными экземпляра, содержащими информацию о версии и фиксации. Это полезно для заполнения панели about about и создания строк регистрации, отчетов о сбоях или сообщений об ошибках пользователей по электронной почте с предварительно заполненной информацией.

Это было весело сделать. Я узнал много о системе сборки Xcode.

Вот пример типа необычной Версии и Строки сборки, которые может автоматически генерировать VersionX.

Версия X 1.0.1 β7 (c5959a3 "Чистый")

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

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

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

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

Ответ 17

Возможно, вы захотите проверить новый инструмент, который я разрабатывал под названием Xcodebump. Он может обрабатывать как CFBundleShortVersionString, так и CFBundleVersion. В качестве последнего шага он также проверит git и пометит фиксацию, чтобы она соответствовала этим значениям CFBundle.

Проект Xcodebump находится здесь:

https://github.com/markeissler/Xcodebump

Ответ 18

Я обновляю 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 another story.
## Examples: `21.1`, or `21.1.3`
build_number="${major_number}.${minor_number}"

У меня есть 2 стратегии для решения $build_number.

Первая стратегия

В этой стратегии используется счетчик git tag, чтобы принять решение major build number. Если есть теги 53 проекта, он вернет 53, следуя оболочке script.

Как правило, он увеличивается. И это заставит разработчика поместить тег git перед публикацией.

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

Вторая стратегия

Пусть Jenkins Система CI решит часть major. Он имеет переменную окружения BUILD_NUMBER. Он автоматически увеличивается при построении системы CI. Эта информация полезна для отслеживания истории проекта в системе CI.

major_number=${BUILD_NUMBER}

Ответ 19

Вот мое решение. Если вы похожи на меня: терминал дружественный, как рубин, как семантическое управление версиями, попробуйте это.

Создайте файл с именем 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

Запустите: rake increment:major или rake increment:minor или rake increment:tiny, когда захотите.

Ответ 20

Вот обновленная версия. Это работает с 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 и установите для "Bundle version" значение 1, а для "Bundle version string, short" значение 1, вы должны быть установлены.

Создайте проект с использованием Info.plist, и вы увидите изменение версии Bundle (номер сборки).

• Обратите внимание, что начиная с Xcode 9.3.1 вы не сможете увидеть эти изменения на вкладке "Общие", но увидите изменения при архивировании сборки и в Info.plist.