blocks|key|3120759|text|如果我没理解错的话，您想修改Project-Info.plist文件，它是Xcode标准项目模板的一部分？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3120760|我问这个问题的原因是，Project-Info.plist通常处于版本控制之下，修改它意味着它将被标记为，嗯，修改。|3120761|如果您对此没有意见，那么下面的代码片段将更新内部版本号，并将该文件标记为在该过程中已修改，其中get_build_number是某个脚本(即本例中的占位符)，以获取您要使用的(可能递增的)内部版本号：|3120762|#!/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|code-block|syntax|javascript|3120763|PlistBuddy允许您在plist文件中设置任何密钥，而不仅仅是版本号。您可以创建所有想要的plist文件，如果需要，可以将它们包含在资源中。然后可以从捆绑包中读取它们。|3120764|至于您需要在about窗格和其他地方显示版本，您还可以查看设置CFBundleGetInfoString和CFBundleShortVersionString。|3120765|entityMap^0|E|I|0|B|I|0|1B|G|0|0|0|V|L|1H|Q|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|13|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|T|$]]

If I understand your question correctly, you want to modify the <code>Project-Info.plist</code> file, which is a part of the standard project template of Xcode? 

The reason I ask this is that <code>Project-Info.plist</code> normally is under version control, and modifying it means that it will be marked as, well, modified. 

If that is fine with you, then the following snippet will update the build number and mark the file as modified in the process, where <code>get_build_number</code> is some script (i.e., a placeholder in this example) to get the (possibly incremented) build number that you want to use:

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

PlistBuddy allows you to set any key in a plist file, not just the version number. You can create all the plist files you want, and include them in the resources if needed. They can then be read in from the bundle.

As to your need to show the version in the about pane and other places, you can also look into setting <code>CFBundleGetInfoString</code> and <code>CFBundleShortVersionString</code>.

blocks|key|236439|text|我尝试了修改后的程序，但它不起作用，因为：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|236440|236441|Xcode+4.2.1更改了.xcodeproj|ordered-list-item|236442|git中的xcuerdata子目录，并注意到了先前在Project-Info.plist|236443|中进行的更改|236444|以下修改会导致忽略这些更改，并仅标记真正的更改：|236445|if+[+-n+"$(find+$dir+\!+-path+"*xcuserdata*"+\!+-path+"*.git"+-newer+$plist)"+];+then|code-block|syntax|javascript|236446|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|Y|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I tried the modified procedure and it did not work, because:-

<ol>
<li>Xcode 4.2.1 changes the xcuserdata subdirectory in .xcodeproj</li>
<li>git notes the previous change in Project-Info.plist</li>
</ol>

The following modification causes these to be ignored and only flags genuine changes:-

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

blocks|key|2906526|text|谢谢你的脚本。它工作得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2906527|我的Info.plist在一个子目录中，其名称包含空格，因此我必须在plist路径两边加上引号来修改运行脚本：|2906528|${PROJECT_DIR}/tools/bump_build_number.sh+"${PROJECT_DIR}/${INFOPLIST_FILE}"|code-block|syntax|javascript|2906529|和shell脚本的方式相同，所有路径都用引号括起来：|2906530|#!/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+%2B+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|2906531|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Thanks for the script. It works great.

My Info.plist is in a subdirectory with a name containing spaces so I had to modify the Run Script with quotes around the plist path:

<pre><code>${PROJECT_DIR}/tools/bump_build_number.sh "${PROJECT_DIR}/${INFOPLIST_FILE}"
</code></pre>

and the shell script in the same way with quotes around all the paths:

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

blocks|key|241667|text|您可能只想在存档(例如上传到TF+)时执行此操作。否则你的版本号可能很快就会上升..|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|241668|在方案(Product+/+Edit+scheme+/+archive+/+Pre-Actions)中，您可以添加仅在存档时才会执行的脚本。|241669|此外，您可能希望在每次递增应用程序版本时重置内部版本号。|241670|最后一件事，如果你使用存档，你可以安全地禁用：|241671|#+if+[+-n+"$(find+"$dir"+\!+-path+"*xcuserdata*"+\!+-path+"*.git"+-newer+"$plist")"+];+then
...
#+else
++++#+echo+"Not+incrementing+build+number+as+source+files+have+not+changed"
#+fi|code-block|syntax|javascript|241672|由于内部版本号将增加，只有当你存档...|241673|编辑:纠正我所说的，存档中的前置操作发生在构建之后(但在存档之前)，因此构建号将在下一次存档时递增...但是您可以创建一个新方案并将此操作添加到此新方案的build+(pre-actions)部分。当您想要创建新的构建时，请使用此方案|241674|entityMap^0|6|2|0|0|0|0|0|F|2|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|11|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|12|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|16|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|V|$]]

You may want to do this only when you archive (and upload to TF for example).
Otherwise your version number might go up really quick.. 

In the scheme (Product / Edit Scheme / Archive / Pre-Actions) you can add a script that will be executed only when you archive.

Also, you might want to reset build number each time you increment the app version.

Last thing, if you use archive instead, you can safely disable:

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

As the build number will be incremented only when you archive...

EDIT: Correct what I said, pre-actions in archive happen after build (but before archiving), so build number will be increment for next archive... But you can create a new scheme and add this action in the build (pre-actions) section of this new scheme. and use this scheme when you want to create a new build

blocks|key|2906659|text|这整个条目非常有帮助。我使用了这个技巧，但在GIT中将我的脚本设置为提交后钩子，因此CFBundleVersion在每次成功提交后都会递增。钩子脚本放在.git/hooks中。在项目目录中会留下一个日志。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2906660|这符合我最基本的标准。我希望能够从GIT中拉出一个版本，并重新构建我以前的版本。在构建过程中执行的任何增量都不会做到这一点。|2906661|下面是我的脚本：|2906662|#!/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+%2B+1)
/usr/libexec/Plistbuddy+-c+"Set+CFBundleVersion+$buildnumplus"+"$plist"

echo+$(date)+"-+Incremented+CFBundleVersion+to"+$buildnumplus+>>+hookLog.txt|code-block|syntax|javascript|2906663|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|P|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This whole entry was extremely helpful. I used this trick but set up my script as a post-commit hook in GIT, so CFBundleVersion is incremented after every successful commit. The hook script goes in .git/hooks. A log is left in the project directory.

This meets my most basic criterion. I want to be able to pull a version from GIT and rebuild the exact build I had previously. Any increment done during the build process does not do this.

Here is my script:

<pre><code>#!/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 &gt;&gt; hookLog.txt
</code></pre>

blocks|key|2906712|text|我已经使用了这个glist。它的工作方式与预期一致。https://gist.github.com/sekati/3172554+(所有功劳都归功于原作者)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2906713|我随着时间的推移修改的脚本。|2906714|xcode-versionString-generator.sh，|2906715|xcode-build-number-generator.sh|2906716|由于这些要点对开发社区有帮助，因此我创建了GitHub项目。所以让我们好好开发它。下面是GitHub项目：https://github.com/alokc83/Xcode-build-and-version-generator|2906717|我已经更新了这两个脚本的代码，并进行了一些增强。从GitHub获取最新版本，而不是使用下面的|style|BOLD|2906718|对于版本：|2906719|#+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+%7C+awk+-F+"."+'{print+$3}'`
NEWSUBVERSION=$(($NEWSUBVERSION+%2B+1))
NEWVERSIONSTRING=`echo+$VERSIONNUM+%7C+awk+-F+"."+'{print+$1+"."+$2+".'$NEWSUBVERSION'"+}'`
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleShortVersionString+$NEWVERSIONSTRING"+"${PROJECT_DIR}/${INFOPLIST_FILE}"|code-block|syntax|javascript|2906720|对于构建：|2906721|#+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+%2B+1))
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$buildNumber"+"${PROJECT_DIR}/${INFOPLIST_FILE}"|2906722|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/sekati/3172554|1|https://gist.github.com/alokc83/5220205|2|https://gist.github.com/alokc83/5207294|3|https://github.com/alokc83/Xcode-build-and-version-generator^0|Q|12|0|0|0|0|W|1|0|0|V|2|0|1H|1O|3|0|0|V|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|H|3|I|5|6|7|1N|8|@]|9|@$A|1O|B|1P|1|1Q]]|C|$]]|$1|J|3|K|5|6|7|1R|8|@]|9|@$A|1S|B|1T|1|1U]]|C|$]]|$1|L|3|M|5|6|7|1V|8|@$A|1W|B|1X|N|O]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|R|3|S|5|T|7|1Z|8|@]|9|@]|C|$U|V]]|$1|W|3|X|5|6|7|20|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|T|7|21|8|@]|9|@]|C|$U|V]]|$1|10|3|-4|5|6|7|22|8|@]|9|@]|C|$]]]|11|$12|$5|13|14|15|C|$16|17]]|18|$5|13|14|15|C|$16|19]]|1A|$5|13|14|15|C|$16|1B]]|1C|$5|13|14|15|C|$16|1D]]]]

I have used this glist. It works as expected. 
<a href="https://gist.github.com/sekati/3172554" rel="nofollow noreferrer">https://gist.github.com/sekati/3172554</a>
(all credit goes to the original author)

Scripts that I modified over time.

<a href="https://gist.github.com/alokc83/5220205" rel="nofollow noreferrer">xcode-versionString-generator.sh</a>,

<a href="https://gist.github.com/alokc83/5207294" rel="nofollow noreferrer">xcode-build-number-generator.sh</a>

As these gist are helping the dev community, I made GitHub project out of it. So let's develop it well. 
Here is the GitHub project:
<a href="https://github.com/alokc83/Xcode-build-and-version-generator" rel="nofollow noreferrer">https://github.com/alokc83/Xcode-build-and-version-generator</a>

I have updated the code for both script little bit of enhancement. 
instead of using below grab the latest from GitHub

For Version :

<pre><code># 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 -&gt; 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}"
</code></pre>

For build:

<pre><code># 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 -&gt; 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}"
</code></pre>

blocks|key|241736|text|我推荐使用autorevision。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|241737|Xcode允许头文件(可以在构建时自动生成，而不是在vcs本身中自动生成)提供将在构建时在info.plist中扩展的值。您可以在autorevision+website上找到设置此设置的演练。|241738|自动修订的输出类型适合于这些类型的头文件，以帮助在这些情况下。|241739|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/Autorevision/autorevision|1|https://autorevision.github.io/Xcode/^0|5|C|0|0|1T|K|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

I would recommend the use of <a href="https://github.com/Autorevision/autorevision" rel="nofollow">autorevision</a>.

Xcode allows for a header file (which can be auto generated at build time and not in the vcs its self) to provide values that will be expanded in the info.plist at build time. You can find a walkthrough for setting this up on the <a href="https://autorevision.github.io/Xcode/" rel="nofollow">autorevision website</a>.

Autorevision has an output type geared towards these types header files to help in exactly these situations.

blocks|key|3121024|text|这是我目前用来增加版本号的(包括存档)的版本号。在Xcode+5.1下运行良好。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3121025|只需直接在Xcode中将代码片段复制/粘贴到运行脚本构建阶段：|3121026|buildnum=$(/usr/libexec/PlistBuddy+-c+"Print+:CFBundleVersion"+"$PRODUCT_SETTINGS_PATH")

if+[+"$CONFIGURATION"+=+"Release"+];+then
buildnum=$((buildnum+%2B+1))
echo+"Build+number+updated+to+$buildnum"
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$buildnum"+"$PRODUCT_SETTINGS_PATH"
fi;|code-block|syntax|javascript|3121027|entityMap^0|N|H|0|0|V|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

FWIW - this is what I'm currently using to increase the build number only for release builds (which includes archiving). Works fine under Xcode 5.1.

Just copy/paste the snippet into a Run script build phase directly in Xcode: 

<pre><code>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;
</code></pre>

blocks|key|241758|text|您可能想看看我正在开发的名为Xcodebump的新工具。它可以处理CFBundleShortVersionString和CFBundleVersion的更新。作为最后一步，它还将签入git并标记提交，以与这些CFBundle值匹配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|241759|Xcodebump+project位于以下位置：|offset|length|241760|https://github.com/markeissler/Xcodebump|241761|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|H|0|0|0|14|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|G]]|O|$5|K|L|M|A|$N|G]]]]

You might want to check out a new tool I've been developing called Xcodebump. It can handle updating both CFBundleShortVersionString and CFBundleVersion. As a final step it will also checkin to git and tag the commit to match up with those CFBundle values.

The <a href="https://github.com/markeissler/Xcodebump" rel="nofollow">Xcodebump project</a> is located here:

<a href="https://github.com/markeissler/Xcodebump" rel="nofollow">https://github.com/markeissler/Xcodebump</a>

blocks|key|2906835|text|关于这个问题，我花了很多心思，但没有一个能让我满意。然而，我最终想出了一个我真正喜欢的混合体！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2906836|我们只需将构建产品的版本号设置为Git提交的数量。这不会扰乱您的源代码控制，因为脚本只会改变构建的产品。|2906837|将这个“运行脚本”构建阶段添加到构建阶段的末尾：|2906838|if+[+"${CONFIGURATION}"+=+"Release"+];+then
++++buildNumber=$(git+rev-list+--count+head)
++++/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$buildNumber"+"${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
fi|code-block|syntax|javascript|2906839|将项目中的Info.plist版本设置为您想要的任何版本，在构建发布版本时将永远不会使用它。我将我的设置为AUTOMATED或DEVELOPMENT，这样当我运行开发构建时就很清楚了。|offset|length|style|CODE|2906840|就这样!构建的应用程序将有一个不断增加的构建数量。(只要您总是在同一分支上进行构建。)|2906841|我喜欢这个方法的原因：|2906842|2906843|Easy|unordered-list-item|2906844|Doesn't污染Git版本history|2906845|CFBundleVersion是完全自动的|2906846|，漂亮的版本号可以随时修改我想要的|2906847|2906848|其他注释：|2906849|2906850|如果您的项目中有应用程序扩展，只需在这些目标上也设置相同的构建脚本即可。这将保持所有版本号的自动化和同步。应用商店需要与您的主应用匹配的扩展版本。|2906851|2906852|entityMap^0|0|0|0|0|1H|9|1R|B|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1F|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1G|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1H|8|@$M|1I|N|1J|O|P]|$M|1K|N|1L|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1M|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1N|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|V|3|W|5|X|7|1P|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|X|7|1Q|8|@]|9|@]|A|$]]|$1|10|3|11|5|X|7|1R|8|@]|9|@]|A|$]]|$1|12|3|13|5|X|7|1S|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1U|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|18|3|19|5|X|7|1W|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|1C|$]]

I've messed around with a lot of the answers on this question, and none of them quite satisfied me. However, I finally came up with a mixture that I really like!
We simply set the version number for the built product to the number of Git commits. This won't mess with your source control, since the script only mutates the built product.
Add this &quot;Run Script&quot; build phase to the end of your build phases:
<pre><code>if [ &quot;${CONFIGURATION}&quot; = &quot;Release&quot; ]; then
 buildNumber=$(git rev-list --count head)
 /usr/libexec/PlistBuddy -c &quot;Set :CFBundleVersion $buildNumber&quot; &quot;${TARGET_BUILD_DIR}/${INFOPLIST_PATH}&quot;
fi
</code></pre>
Set your Info.plist version in your project to whatever you want, it will never get used when building a release build. I set mine to <code>AUTOMATED</code> or <code>DEVELOPMENT</code> so it's clear when I'm running a development build.
That's it! The built app will have a constantly increasing build number. (As long as you always do your builds off the same branch.)
Why I like this method:
<ul>
<li>Easy</li>
<li>Doesn't pollute Git version history</li>
<li>CFBundleVersion is totally automatic</li>
<li>The pretty version number can be modified whenever I want</li>
</ul>
Other notes:
<ul>
<li>If you have app extensions in your project, simply set the same build script on those targets too. This will keep all the version numbers automated and in sync. The App Store requires extension versions match your main app.</li>
</ul>

blocks|key|2906899|text|这是我的解决方案。如果你像我一样:终端友好，像ruby，像语义版本控制，试试这个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2906900|创建一个名为Rakefile的文件，其中包含以下内容：|offset|length|style|CODE|2906901|require+"xcodeproj"
require+"versionomy"

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

$UPDATES+=+[:major,:minor,:tiny]
$UPDATES.each+{+%7Cpart%7C
++desc+"increment+#{part}+part+of+version"
++task+"increment:#{part}"+do+%7Ctask%7C
++++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
}|code-block|syntax|javascript|2906902|准备：gem+install+xcodeproj+versionomy|2906903|随时运行：rake+increment:major、rake+increment:minor或rake+increment:tiny。|2906904|entityMap^0|0|6|8|0|0|3|W|0|5|K|Q|K|1B|J|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|G]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$]]

Here's my solution.
If you're like me: terminal friendly, like ruby, like semantic versioning, try this.

Make a file named <code>Rakefile</code> which contains this:

<pre><code>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
}
</code></pre>

Prepare: <code>gem install xcodeproj versionomy</code>

Run: <code>rake increment:major</code> or <code>rake increment:minor</code> or <code>rake increment:tiny</code> whenever you want.

blocks|key|240170|text|我使用最新的SVN修订版作为内部版本号。如果您更改了build目录中的Info.plist，则不会影响源Info.plist：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240171|#+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+%7C+awk+'/'"Status+against+revision:"'/+{print+$4}'`|code-block|syntax|javascript|240172|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I use the last SVN revision for the build number. If you change the Info.plist in the build directory, you won't affect the source Info.plist:

<pre><code># 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}'`
</code></pre>

blocks|key|240204|text|在Wil+Gieseler's+solution的基础上，我只想做一个改变。他的解决方案将git提交数计入内部版本号。很有用，但要找到创建该构建的实际提交仍然是一件痛苦的事情。我并不太关心构建号是否单调增加，所以我放弃了这个要求，这样我就可以更容易地访问生成给定二进制文件的提交。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|240205|为此，我将他的第一个脚本修改为：|240206|#+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>"|code-block|syntax|javascript|240207|这会将当前git+SHA的短版本转换为十进制。十六进制字符不能很好地满足Apple的内部版本号要求，这就是我必须这么做的原因。要将其转换回来，只需运行如下命令：|240208|SHA=$(bc+<<<+"ibase=10;obase=16;<build+number>")|240209|在bash中，<build+number>是从二进制文件中获得的内部版本号。然后，只需运行git+checkout+$SHA，就可以了。|style|CODE|240210|如上所述，由于这是对Wil+Gieseler's+solution的改编，因此您还需要以下构建后脚本：|240211|#+Set+the+build+number+to+"DEVELOPMENT"
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+DEVELOPMENT"+"${PROJECT_DIR}/${INFOPLIST_FILE}"|240212|这会让你的git历史保持干净。|240213|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/24750392/1292061|1^0|1|N|0|0|0|0|0|0|7|E|19|H|0|A|N|1|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1C|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1D|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|1E|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1F|8|@$A|1G|B|1H|Q|R]|$A|1I|B|1J|Q|R]]|9|@]|C|$]]|$1|S|3|T|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|U|3|V|5|H|7|1O|8|@]|9|@]|C|$I|J]]|$1|W|3|X|5|6|7|1P|8|@]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]|16|$5|11|12|13|C|$14|15]]]]

Building on <a href="https://stackoverflow.com/a/24750392/1292061">Wil Gieseler's solution</a>, I had just one change I wanted to make. His solution puts the count of git commits into the build number. Useful, but still kind of a pain to find the actual commit that created that build. I didn't care too much whether the build number was monotonically increasing, and so I dropped that requirement so that I could more easily access the commit that generated a given binary.

To that end, I modified his first script to the following:

<pre><code># 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:]' &lt;&lt;&lt; "$SHA")
# Use bc to convert the uppercase SHA from hex to decimal
BUILD_NUM=$(bc &lt;&lt;&lt; "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 &lt;build number&gt;
# bc &lt;&lt;&lt; "ibase=10;obase=16;&lt;build number&gt;"
</code></pre>

This converts the short version of the current git SHA into decimal. Hexadecimal characters don't play nicely with Apple's build number requirements, which is why I had to do this. To convert it back, you'd simply run something like this:

<pre><code>SHA=$(bc &lt;&lt;&lt; "ibase=10;obase=16;&lt;build number&gt;")
</code></pre>

in bash, where <code>&lt;build number&gt;</code> is the build number you got from a binary. Then, just run <code>git checkout $SHA</code>, and there you go.

Because this is an adaptation of <a href="https://stackoverflow.com/a/24750392/1292061">Wil Gieseler's solution</a>, as mentioned above, you'll also need the following post-build script:

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

which keeps your git history clean.

blocks|key|240215|text|我目前使用的脚本在很大程度上基于上面的Alix's。我的适应，在下面，添加了一个检查，只在发布/归档版本上执行自动递增。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|240216|如果没有该更改，将会出现版本控制冲突，因为每个开发人员都会以自己的速率递增内部版本号。事实上，git历史将不必要地受到内部版本号不断变化的污染。|240217|#+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+%2B+1))
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$buildNumber"+"${PROJECT_DIR}/${INFOPLIST_FILE}"|code-block|syntax|javascript|240218|它也可以作为GitHub+gist使用(以一种更容易复制和粘贴的格式)。|240219|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/15483906/209828|1|https://gist.github.com/mattpotts/abcffea6d08ad45739ef^0|J|6|0|0|0|0|6|B|1|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]]]

The script I'm currently using is very much based on <a href="https://stackoverflow.com/a/15483906/209828" title="Alix&#39;s Answer">Alix's</a>, above. My adaptation, below, adds a check to only do the auto-increment on a release/archive build.

Without that change there will be version control conflicts as each developer will be incrementing the build number at their own rate. And the fact that the git history would be unnecessarily polluted with the build number changing all the time.

<pre><code># 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 -&gt; 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}"
</code></pre>

It's also available (in a slightly easier to copy and paste format) as a <a href="https://gist.github.com/mattpotts/abcffea6d08ad45739ef" rel="nofollow noreferrer" title="github gist">GitHub gist</a>.

blocks|key|3121265|text|您可以使用Apple's+generic+versioning。基本上，您所要做的就是从托管.xcproj文件的目录中调用agvtool+next-version+-all。有关更多详细信息，请查看上面的url。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3121266|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.apple.com/library/ios/qa/qa1827/_index.html^0|1P|P|5|Q|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

You could use <a href="https://developer.apple.com/library/ios/qa/qa1827/_index.html" rel="noreferrer" title="Apple&#39;s generic versioning">Apple's generic versioning</a>. Basically all you have to do is call <code>agvtool next-version -all</code> from within the directory that hosts your .xcproj file. For more details check out the url above.

blocks|key|3121418|text|我不知道哪种方法是最好的，但我会把苹果的答案发布出来，以防有人在搜索它……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3121419|根据这个Apple's+Q&A+post|offset|length|3121420|使用agvtool自动执行版本号和内部版本号|3121421|版本和内部版本号键分别指定应用程序的市场和内部版本。agvtool是一个命令行工具，允许您自动将这些数字递增到下一个最高数字或特定数字。|style|BOLD|3121422|内部版本号标识应用程序的未发布或已发布版本。它以CFBundleVersion(捆绑包版本)的形式存储在应用程序的Info.plist中。|CODE|3121423|您必须在Xcode项目中完成以下步骤：|3121424|3121425|Enable+agvtool|ordered-list-item|3121426|3121427|导航到目标的Build+Settings窗格，然后为您的所有构建配置更新它，如下所示：|3121428|3121429|将当前项目版本设置为您选择的值。|unordered-list-item|3121430|3121431|Xcode项目数据文件project.pbxproj包含CURRENT_PROJECT_VERSION+(当前项目版本)构建设置，该设置指定项目的当前版本。agvtool在project.pbxproj中搜索CURRENT_PROJECT_VERSION。如果CURRENT_PROJECT_VERSION存在，它将继续运行，否则将停止运行。它的值用于更新内部版本号。|3121432|3121433|将版本控制系统设置为苹果通用。|3121434|3121435|默认情况下，Xcode不使用任何版本控制系统。将版本控制系统设置为Apple+Generic可确保Xcode在项目中包含所有agvtool生成的版本信息。|3121436|​|3121437|📷|atomic|3121438|3121439|对您的版本进行|3121440|Set更新并构建numbers|3121441|3121442|agvtool在你的应用程序的Info.plist中搜索你的版本和版本号。如果它们存在，它会更新它们，否则什么也不做。确保Info.plist中存在CFBundleVersion+(捆绑包版本)和CFBundleShortVersionString+(捆绑包版本字符串，简称)密钥，如下图所示：|3121443|3121444|3121445|3121446|退出Xcode，然后导航到终端应用程序中包含.xcodeproj项目文件的目录，然后运行以下任何命令。.xcodeproj项目文件包含agvtool使用的project.pbxproj。(这是您可以在脚本而不是命令行中运行的部分。)|3121447|更新版本号的|3121448|要将版本号更新为特定版本，请运行|3121449|xcrun+agvtool+new-marketing-version+<your_specific_version>|code-block|syntax|javascript|3121450|Ex:将版本号更新为2.0|3121451|xcrun+agvtool+new-marketing-version+2.0|3121452|更新内部版本号的|3121453|要自动递增内部版本号，请运行|3121454|xcrun+agvtool+next-version+-all|3121455|若要将应用程序的内部版本号设置为特定版本，请运行|3121456|xcrun+agvtool+new-version+-all+<your_specific_version>|3121457|Ex:将内部版本号设置为2.6.9|3121458|xcrun+agvtool+new-version+-all+2.6.9|3121459|奖励：|3121460|要查看当前版本号，请运行|3121461|xcrun+agvtool+what-marketing-version|3121462|要查看当前的内部版本号，请运行|3121463|xcrun+agvtool+what-version|3121464|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.apple.com/library/ios/qa/qa1827/_index.html|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/9cfdf3832cd95b6021529832b8def438.png|imageAlt|2|https://ask.qcloudimg.com/http-save/yehe-900000/0166e3ef16b70b7ff64a74ee0c5b0bad.png^0|0|4|G|0|0|0|0|1W|0|0|1X|O|F|0|0|J|0|0|0|E|0|0|0|17|0|0|0|G|0|0|0|54|S|N|2W|N|3M|N|0|0|0|F|0|0|0|25|0|0|1|0|0|1|0|1|1|0|0|1|0|0|7|0|0|F|0|0|0|43|22|F|2Q|Q|0|0|1|0|0|1|0|1|2|0|0|1|0|0|38|0|0|5|0|0|G|0|0|0|D|0|0|0|7|0|0|E|0|0|0|O|0|0|0|H|0|0|0|3|0|0|C|0|0|0|F|0|0^^$0|@$1|2|3|4|5|6|7|39|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|3A|8|@]|9|@$D|3B|E|3C|1|3D]]|A|$]]|$1|F|3|G|5|6|7|3E|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|3F|8|@$D|3G|E|3H|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|3I|8|@$D|3J|E|3K|J|K]|$D|3L|E|3M|J|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|3N|8|@$D|3O|E|3P|J|K]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|3R|8|@$D|3S|E|3T|J|K]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|3V|8|@$D|3W|E|3X|J|K]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|3Z|8|@$D|40|E|41|J|K]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|42|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|43|8|@$D|44|E|45|J|K]|$D|46|E|47|J|N]|$D|48|E|49|J|N]|$D|4A|E|4B|J|N]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|4C|8|@]|9|@]|A|$]]|$1|15|3|16|5|10|7|4D|8|@$D|4E|E|4F|J|K]]|9|@]|A|$]]|$1|17|3|-4|5|6|7|4G|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|4H|8|@$D|4I|E|4J|J|K]]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|4K|8|@$D|4L|E|4M|J|K]]|9|@]|A|$]]|$1|1C|3|1D|5|1E|7|4N|8|@$D|4O|E|4P|J|K]]|9|@$D|4Q|E|4R|1|4S]]|A|$]]|$1|1F|3|1B|5|6|7|4T|8|@$D|4U|E|4V|J|K]]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|4W|8|@$D|4X|E|4Y|J|K]]|9|@]|A|$]]|$1|1I|3|1J|5|T|7|4Z|8|@$D|50|E|51|J|K]]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|52|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|53|8|@$D|54|E|55|J|K]|$D|56|E|57|J|N]|$D|58|E|59|J|N]]|9|@]|A|$]]|$1|1N|3|1B|5|6|7|5A|8|@$D|5B|E|5C|J|K]]|9|@]|A|$]]|$1|1O|3|1D|5|1E|7|5D|8|@$D|5E|E|5F|J|K]]|9|@$D|5G|E|5H|1|5I]]|A|$]]|$1|1P|3|1B|5|6|7|5J|8|@$D|5K|E|5L|J|K]]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|5M|8|@$D|5N|E|5O|J|K]]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|5P|8|@$D|5Q|E|5R|J|K]]|9|@]|A|$]]|$1|1U|3|1V|5|6|7|5S|8|@$D|5T|E|5U|J|K]]|9|@]|A|$]]|$1|1W|3|1X|5|1Y|7|5V|8|@]|9|@]|A|$1Z|20]]|$1|21|3|22|5|6|7|5W|8|@$D|5X|E|5Y|J|K]]|9|@]|A|$]]|$1|23|3|24|5|1Y|7|5Z|8|@]|9|@]|A|$1Z|20]]|$1|25|3|26|5|6|7|60|8|@$D|61|E|62|J|K]]|9|@]|A|$]]|$1|27|3|28|5|6|7|63|8|@$D|64|E|65|J|K]]|9|@]|A|$]]|$1|29|3|2A|5|1Y|7|66|8|@]|9|@]|A|$1Z|20]]|$1|2B|3|2C|5|6|7|67|8|@$D|68|E|69|J|K]]|9|@]|A|$]]|$1|2D|3|2E|5|1Y|7|6A|8|@]|9|@]|A|$1Z|20]]|$1|2F|3|2G|5|6|7|6B|8|@$D|6C|E|6D|J|K]]|9|@]|A|$]]|$1|2H|3|2I|5|1Y|7|6E|8|@]|9|@]|A|$1Z|20]]|$1|2J|3|2K|5|6|7|6F|8|@$D|6G|E|6H|J|K]]|9|@]|A|$]]|$1|2L|3|2M|5|6|7|6I|8|@$D|6J|E|6K|J|K]]|9|@]|A|$]]|$1|2N|3|2O|5|1Y|7|6L|8|@]|9|@]|A|$1Z|20]]|$1|2P|3|2Q|5|6|7|6M|8|@$D|6N|E|6O|J|K]]|9|@]|A|$]]|$1|2R|3|2S|5|1Y|7|6P|8|@]|9|@]|A|$1Z|20]]|$1|2T|3|-4|5|6|7|6Q|8|@]|9|@]|A|$]]]|2U|$2V|$5|2W|2X|2Y|A|$2Z|30]]|31|$5|32|2X|33|A|$34|35|36|-4]]|37|$5|32|2X|33|A|$34|38|36|-4]]]]

I don't know which way is the best, but I will post Apple's answer just in case anybody is searching for it...

According to this <a href="https://developer.apple.com/library/ios/qa/qa1827/_index.html" rel="noreferrer">Apple's Q&amp;A post</a>:

<h1>Automating Version and Build Numbers Using agvtool</h1>

The version and build number keys respectively specify the marketing and internal versions of your application. agvtool is a command-line tool that allows you to automatically increment these numbers to the next highest number or to a specific number.

The build number identifies an unreleased or released version of your application. It is stored in your application’s Info.plist as <code>CFBundleVersion</code>(Bundle version). 

You must complete the following steps in your Xcode project:

<ol>
<li>Enable agvtool</li>
</ol>

Navigate to the Build Settings pane of your target, then update it for all your build configurations as follows:

<ul>
<li>Set Current Project Version to a value of your choosing.</li>
</ul>

Your Xcode project data file, project.pbxproj, includes a <code>CURRENT_PROJECT_VERSION</code> (Current Project Version) build setting, which specifies the current version of your project. agvtool searches project.pbxproj for <code>CURRENT_PROJECT_VERSION</code>. It continues running if <code>CURRENT_PROJECT_VERSION</code> exists and stops running, otherwise. Its value is used to update the build number.

<ul>
<li>Set Versioning System to Apple Generic.</li>
</ul>

By default, Xcode does not use any versioning system. Setting Versioning System to Apple Generic ensures that Xcode will include all agvtool-generated version information in your project.

<a href="https://i.stack.imgur.com/dpKvr.png" rel="noreferrer"><img src="https://i.stack.imgur.com/dpKvr.png" alt="Set Versioning System to Apple Generic"></a>

<ol start="2">
<li>Set up your version and build numbers</li>
</ol>

agvtool searches your application’s Info.plist for your version and build numbers. It updates them if they exist and does nothing, otherwise. Make sure that the <code>CFBundleVersion</code> (Bundle version) and <code>CFBundleShortVersionString</code> (Bundle versions string, short) keys exist in your Info.plist as seen in the image below:

<a href="https://i.stack.imgur.com/ACHdK.png" rel="noreferrer"><img src="https://i.stack.imgur.com/ACHdK.png" alt="Set up your version and build numbers"></a>

Quit Xcode, then navigate to the directory containing your .xcodeproj project file in the Terminal application before running any of the following commands. The .xcodeproj project file contains project.pbxproj, which is used by agvtool. (This is the part you can run in a script instead of command line.)

Updating the Version Number

To update the version number to a specific version, run

<pre><code>xcrun agvtool new-marketing-version &lt;your_specific_version&gt;
</code></pre>

Ex: Update the version number to 2.0

<pre><code>xcrun agvtool new-marketing-version 2.0
</code></pre>

Updating the Build Number

To automatically increment your build number, run

<pre><code>xcrun agvtool next-version -all
</code></pre>

To set the build number of your application to a specific version, run

<pre><code>xcrun agvtool new-version -all &lt;your_specific_version&gt;
</code></pre>

Ex: Set the build number to 2.6.9

<pre><code>xcrun agvtool new-version -all 2.6.9
</code></pre>

Bonus:

To view the current version number, run

<pre><code>xcrun agvtool what-marketing-version
</code></pre>

To view the current build number, run

<pre><code>xcrun agvtool what-version
</code></pre>

blocks|key|240295|text|我通过下面的方法更新build+number。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|240296|$INFO_FILE是plist文件的路径。$build_number是此建筑的新内部版本号。|240297|/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$build_number"+"${INFO_FILE}"|code-block|syntax|javascript|240298|通常，我的$build_number由major和minor部件组成。minor来自项目信息。因此，我将介绍如何生成major部件。|240299|##+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}"|240300|我有两个策略来决定$build_number。|240301|第一战略|240302|该策略使用git+tag计数来确定build+number的major。如果有项目的53标签，则通过下面的外壳脚本返回53。|240303|一般来说，这个数字还在增加。这将迫使开发人员在发布之前放置一个git标签。|240304|major_number=$(git+tag+-l+%7C+wc+-l+%7C+grep+-oE+"\d%2B")|240305|第二个策略|240306|让Jenkins+CI系统决定major部分。它有一个环境变量BUILD_NUMBER。在CI系统上构建时，它会自动增加。此信息对于跟踪CI系统上的项目历史很有用。|240307|major_number=${BUILD_NUMBER}|240308|entityMap|0|LINK|mutability|MUTABLE|url|https://jenkins.io/^0|A|C|0|0|A|M|D|0|0|5|D|J|5|P|5|Z|5|1M|5|0|0|9|D|0|0|5|7|H|C|U|5|16|2|1N|2|0|0|0|0|F|5|V|C|1|7|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1H|8|@$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|1M|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1N|8|@$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]]|D|@]|E|$]]|$1|O|3|P|5|J|7|1Y|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1Z|8|@$9|20|A|21|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|22|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|23|8|@$9|24|A|25|B|C]|$9|26|A|27|B|C]|$9|28|A|29|B|C]|$9|2A|A|2B|B|C]|$9|2C|A|2D|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2E|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|J|7|2F|8|@]|D|@]|E|$K|L]]|$1|10|3|11|5|6|7|2G|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|2H|8|@$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]]|D|@$9|2M|A|2N|1|2O]]|E|$]]|$1|14|3|15|5|J|7|2P|8|@]|D|@]|E|$K|L]]|$1|16|3|-4|5|6|7|2Q|8|@]|D|@]|E|$]]]|17|$18|$5|19|1A|1B|E|$1C|1D]]]]

I update <code>build number</code> by following method.

<code>$INFO_FILE</code> is the path of the plist file.
And <code>$build_number</code> is a new build number for this building. 

<pre><code>/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build_number" "${INFO_FILE}"
</code></pre>

Generally, my <code>$build_number</code> is composed by <code>major</code> and <code>minor</code> parts.
The <code>minor</code> is come from project information. So I describe how to generate the <code>major</code> part.

<pre><code>## 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}"
</code></pre>

I have 2 strategies to decide the <code>$build_number</code>.

<h2>First Strategy</h2>

This strategy uses the <code>git tag</code> count to decide the <code>major</code> of <code>build number</code>. If there are <code>53</code> tags of the project, it will return <code>53</code> by following shell script.

Generally, it's increasing. And it will force the developer to put a git tag before publishing.

<pre><code>major_number=$(git tag -l | wc -l | grep -oE "\d+")
</code></pre>

<h2>Second Strategy</h2>

Let <a href="https://jenkins.io" rel="nofollow">Jenkins</a> CI system decide the <code>major</code> part. It has an environment variable <code>BUILD_NUMBER</code>. It is increasing automatically when building on the CI system. This information is useful to trace the project history on the CI system.

<pre><code>major_number=${BUILD_NUMBER}
</code></pre>

blocks|key|240333|text|这是一个更新的版本。这在Xcode9.3.1，iOS+11中起作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240334|从应用程序目标单击“Build+Phases”，单击%2B图标以添加新的运行脚本，然后在框中粘贴此代码。|240335|buildNumber=$(/usr/libexec/PlistBuddy+-c+"Print+CFBundleVersion"+"${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber+%2B+1))
/usr/libexec/PlistBuddy+-c+"Set+:CFBundleVersion+$buildNumber"+"${PROJECT_DIR}/${INFOPLIST_FILE}"|code-block|syntax|javascript|240336|进入Info.plist文件，将“Bundle+version”设置为1，并将“Bundle+versions+string，short”设置为1。|240337|使用视图中的Info.plist构建项目，您应该会看到Bundle版本(内部版本号)发生了变化。|240338|240339|请注意，从Xcode9.3.1开始，您将无法从常规选项卡中看到这些更改，但在归档生成时以及在Info.plist|unordered-list-item|240340|中将会看到这些更改|240341|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Heres an updated version. This works as of Xcode 9.3.1, iOS 11.

Click on 'Build Phases' from your application target, click the + icon to add a new run script, and in the box, paste this code.

<pre><code>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}"
</code></pre>

Go into the Info.plist file and set the 'Bundle version' to 1, and the 'Bundle versions string, short' to 1, you should be set.

Build the project with Info.plist in view, and you should see the Bundle version (Build number) change.

<ul>
<li>Note that as of Xcode 9.3.1, you will not be able to see these changes from the general tab, but will see the changes when you archive a build, and in Info.plist</li>
</ul>

blocks|key|3121614|text|我觉得我找到了我的部落。部落，我希望你被VersionX逗乐了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3121615|十年前，当我在一个有超过25个Xcode项目的工作区工作时，如果你只维护一两个偶尔更新的项目，我会利用这个机会自动化版本并构建字符串更新，这可能看起来很荒谬。|3121616|VersionX:|offset|length|style|BOLD|3121617|3121618|知道构建类型(发布/调试)|unordered-list-item|3121619|在构建时从存储库收集信息(包括git支持，但可以针对hg、svn或任何您使用的内容进行自定义)|3121620|为易于自定义的奇特营销版本字符串(在应用商店实施约定之前有更多变化)提供，因此您可以使用git标签约定自动递增包含"beta“符号的字符串，对于example.|3121621|includes，使用包含版本和提交信息的实例变量填充的类。这对于填充about面板和使用预先填充的信息构建日志字符串、崩溃报告或用户电子邮件错误报告非常有用。|3121622|3121623|这是一个有趣的制作。我学到了大量关于Xcode构建系统的知识。|3121624|下面是VersionX可以自动生成的奇特版本和构建字符串类型的示例。|3121625|VersionX+1.0.1清洁7+(c5959a3“干净”)|3121626|营销版本：+VersionX+1.0.1β7+"1.0.1是从提交的标签派生的，而“Beta7”是由提交计数或构建计数(例如)自动生成的。|3121627|干净构建版本：+(c5959a3“”)显示短提交散列，并通知您构建目录没有未提交的更改。|3121628|VersionX+(source+at+GitHub)+-+a+baroque+system+for+automatically+incrementing+version+and+build+strings+in+Xcode+projects.|3121629|The+VersionX+Documentation.|3121630|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/illumineX/VersionX|1|https://github.com/illumineX/VersionX/wiki^0|0|0|0|9|0|0|0|0|0|0|0|0|0|0|V|0|0|5|0|H|R|0|0|3E|0|3E|0|0|0|R|0|R|1|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1K|8|@$F|1L|G|1M|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1O|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|1P|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|1Q|8|@]|9|@]|A|$]]|$1|R|3|S|5|M|7|1R|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1T|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1U|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1V|8|@$F|1W|G|1X|H|I]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1Y|8|@$F|1Z|G|20|H|I]]|9|@]|A|$]]|$1|12|3|13|5|6|7|21|8|@$F|22|G|23|H|I]]|9|@]|A|$]]|$1|14|3|15|5|6|7|24|8|@$F|25|G|26|H|I]]|9|@$F|27|G|28|1|29]]|A|$]]|$1|16|3|17|5|6|7|2A|8|@$F|2B|G|2C|H|I]]|9|@$F|2D|G|2E|1|2F]]|A|$]]|$1|18|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]]|19|$1A|$5|1B|1C|1D|A|$1E|1F]]|1G|$5|1B|1C|1D|A|$1E|1H]]]]

I feel like I've found my tribe. Tribe, I hope you're amused by VersionX.

A decade ago while working on a workspace that had over 25 Xcode projects in it I took the opportunity to automate the version and build string updates to a degree which might seem absurd, if you're maintaining only a project or two with occasional updates. 

VersionX:

<ul>
<li>is aware of the build type (Release / Debug)</li>
<li>gathers information at build time from the repository (git support included, but can be customized for hg, svn, or whatever you use)</li>
<li>provided for easily customizable fancy marketing version strings (which had much more variation before the App Store imposed a convention) so you could automatically increments strings which included symbols for a "beta" using a git tag convention, for example.</li>
<li>includes a class populated with instance variables containing version and commit information. This is useful for populating your about panel and constructing logging strings, crash reports, or user email bug reports with pre-populated information. </li>
</ul>

It was fun to make. I learned a boatload about the Xcode build system.

Here's an example of the type of fancy Version and Build strings VersionX could automatically generate.

VersionX 1.0.1 β7 (c5959a3 “Clean”)

Marketing Version: VersionX 1.0.1 β7
The "1.0.1 is derived from the tag for the commit, while
The “Beta 7” is automatically generated by the commit count, or build count (for example).

Build Version: (c5959a3 “Clean”)
Displays the short commit hash, and informs you that the build directory had zero uncommitted changes.

<a href="https://github.com/illumineX/VersionX" rel="nofollow noreferrer" title="VersionX at GitHub">VersionX (source at GitHub) - a baroque system for automatically incrementing version and build strings in Xcode projects.</a>

<a href="https://github.com/illumineX/VersionX/wiki" rel="nofollow noreferrer" title="VersionX Documentation">The VersionX Documentation.</a>

blocks|key|239187|text|我发现使用Automating+Version+and+Build+Numbers+Using+agvtool最方便。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|239188|试试这个：|239189|239190|按照上面链接的苹果文档中的说明进行配置。|ordered-list-item|239191|将script作为预操作添加到+->编辑方案...从<your_app_target>提供构建设置->归档(或其他)|style|BOLD|CODE|239192|Set|239193|239194|脚本(第一行是可选的)：|239195|exec+>+${PROJECT_DIR}/prebuild.log+2>&1
cd+${PROJECT_DIR}
xcrun+agvtool+next-version+-all
cd+-|code-block|syntax|javascript|239196|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.apple.com/library/archive/qa/qa1827/_index.html^0|5|1E|0|0|0|0|0|1|6|Q|H|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1C|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|1D|8|@$A|1E|B|1F|L|M]|$A|1G|B|1H|L|N]]|9|@]|C|$]]|$1|O|3|P|5|I|7|1I|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|1K|8|@]|9|@]|C|$]]|$1|T|3|U|5|V|7|1L|8|@]|9|@]|C|$W|X]]|$1|Y|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]]]

I find it most convinient to use <a href="https://developer.apple.com/library/archive/qa/qa1827/_index.html" rel="nofollow noreferrer">Automating Version and Build Numbers Using agvtool</a>.

Try this:

<ol>
<li>Configure it as described in Apple's documentation linked above.</li>
<li>Add script as Pre-action to Project -> Edit Scheme... -> Archive (or other if you prefer)</li>
<li>Set: Provide build settings from <code>&lt;your_app_target&gt;</code></li>
</ol>

The script (first line is optional):

<pre><code>exec &gt; ${PROJECT_DIR}/prebuild.log 2&gt;&amp;1
cd ${PROJECT_DIR}
xcrun agvtool next-version -all
cd -
</code></pre>

blocks|key|240416|text|让我们用苹果自己的方式来做这件事。它将在每次成功生成后增加内部版本号|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240417|我将引导你通过5个图像，只需通过它。|240418|240419|选择‘编辑方案...’从下拉列表中选择位于Stop_build_button右侧的项目名称。Check+First+Step|ordered-list-item|offset|length|240420|From+leftSide菜单展开'+build‘选项并选择'Post-actions’Check+Second+Step|240421|Here你可以添加你想要在成功构建你的程序后执行的代码(脚本)。它是我们必须添加少量代码以使我们的自动化完美工作的地方。1.从leftSide角选择'add+(%2B)‘按钮以添加新的脚本文件>>+2.现在从下拉列表中选择'New+Run+script+>>’>>有3个字段>>+1.+shell已经为你分配了>>+2.现在为‘提供你的构建设置’选择你的项目名称。>>+3.有一个很大的字段可以添加脚本，只需复制并通过此处的代码：Check+Fourth+Step|240422|240423|PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}“"$PLIST"|240424|After+=/+Check+Fifth+Step|unordered-list-item|240425|
+/libexec/PlistBuddy+LAST_NUMBER=$($PLB+-c+"Print+CFBundleVersion”"$PLIST")+NEW_VERSION=$(($LAST_NUMBER+%2B+1))+$PLB+-c+"Set+:CFBundleVersion+$NEW_VERSION“Check+Fifth+Step完成第4步只需选择'+close‘关闭窗口，我们必须执行最后一步，转到项目文件菜单中的'plist.info’文件，并确保'+key‘部分下的'Bundle+Version’键大多数包含数值libexec|240426|entityMap|0|LINK|mutability|MUTABLE|url|https://i.stack.imgur.com/xJBQT.png|1|https://i.stack.imgur.com/eNDLw.png|2|https://i.stack.imgur.com/Y2a7h.png|3|https://i.stack.imgur.com/JsqZl.png|4^0|0|0|0|1A|G|0|0|18|H|1|0|5X|H|2|0|0|0|9|G|3|0|4A|G|4|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1D|8|@]|9|@$H|1E|I|1F|1|1G]]|A|$]]|$1|J|3|K|5|G|7|1H|8|@]|9|@$H|1I|I|1J|1|1K]]|A|$]]|$1|L|3|M|5|G|7|1L|8|@]|9|@$H|1M|I|1N|1|1O]]|A|$]]|$1|N|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1R|8|@]|9|@$H|1S|I|1T|1|1U]]|A|$]]|$1|T|3|U|5|6|7|1V|8|@]|9|@$H|1W|I|1X|1|1Y]]|A|$]]|$1|V|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|12]]|13|$5|Y|Z|10|A|$11|14]]|15|$5|Y|Z|10|A|$11|16]]|17|$5|Y|Z|10|A|$11|18]]|19|$5|Y|Z|10|A|$11|18]]]]

Let's do this in Apple's own way.
It will increase the build number after each successful build

I will guide you through 5 images, just go through it.

<ol>
<li>Select 'Edit Scheme...' from the dropdown, when you select your Project name located in right side to the Stop_build_button.
<a href="https://i.stack.imgur.com/xJBQT.png" rel="nofollow noreferrer">Check First Step</a></li>
<li>From leftSide menu expand the 'Build' option and select 'Post-actions'
<a href="https://i.stack.imgur.com/eNDLw.png" rel="nofollow noreferrer">Check Second Step</a></li>
<li>Here you can add your desired Codes(Scripts) you want to execute after successful build of your program. It is the place where we have to add a little amount of code to make our automation work perfectly. >> 1. select the 'add (+)' button from leftSide corner to add new script file >> 2. Now from the drop down select 'New Run Script Action'
<a href="https://i.stack.imgur.com/6nUm6.png" rel="nofollow noreferrer">Check Third Step</a></li>
<li>It has 3 fields >> 1. shell is already assigned for you >> 2. now for 'Provide you build settings from' Select your Project Name. >> 3. Theres a big field to add your Script, just copy and past this code there : <a href="https://i.stack.imgur.com/Y2a7h.png" rel="nofollow noreferrer">Check Fourth Step</a>

PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}"
PLB=/usr/libexec/PlistBuddy
LAST_NUMBER=$($PLB -c "Print CFBundleVersion" "$PLIST")
NEW_VERSION=$(($LAST_NUMBER + 1))
$PLB -c "Set :CFBundleVersion $NEW_VERSION" "$PLIST"</li>
<li>After completing the 4th step just select 'Close' to close the window and we have to do the last step, Goto your 'plist.info' file in Project file menu and make sure 'Bundle Version' key under 'Key' Section most contain a Numeric Value <a href="https://i.stack.imgur.com/JsqZl.png" rel="nofollow noreferrer">Check Fifth Step</a></li>
</ol>

I have been using a shell script as part of my Xcode build process to increment the build number within the plist file, however it's making Xcode 4.2.1 crash frequently (with an error about the target not belonging to a project; I'm guessing the changing of the plist file is confusing Xcode in some way).

The shell script did this so that the build number is only incremented by <code>agvtool</code> when a file is newer than the plist file (so just building didn't increment the value):

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

Is there a way to increment the build number (in the plist file, or anywhere else) that doesn't break Xcode?

FINAL EDIT: I now do this kind of stuff using a python script which I have just made public on <a href="https://github.com/trojanfoe/xcodedevtools" rel="noreferrer">github</a>. It's not well documented but shouldn't be difficult to work out. As a bonus this repo also contains a useful script to automatically bundle 3rd party library into an app bundle.

Better way of incrementing build number?

版本控制系统

命令行工具

GitHub

Xcode

我一直在使用shell脚本作为Xcode构建过程的一部分，以增加plist文件中的内部版本号，但是这会使Xcode 4.2.1频繁崩溃(出现一个关于目标不属于某个项目的错误；我猜plist文件的更改在某种程度上会混淆Xcode )。shell脚本这样做是为了当文件比plist文件新时，内部版本号才会按agvtool递增...

问增加内部版本号的更好方法？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问增加内部版本号的更好方法？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问增加内部版本号的更好方法？
EN