|
|
The general rule for project versioning is the following:
|
|
|
|
|
|
Version (`CFBundleShortVersionString`) should always follow Semantic Versioning format (http://semver.org), so that version always consists of 3 integers, separated by dot: MAJOR.MINOR.PATCH, e.g. 1.0.0.
|
|
|
|
|
|
Build (`CFBundleVersion`) should always start with 1 and be incremented with each build (archive). It should be reset with each version change. E.g. if current version is 1.0.1 and build is 19 and we change version to 1.0.2 - we should reset build to 1.
|
|
|
|
|
|
This guide will teach you how to setup automatic build versioning with 2 ways - just automatic increment or setting build's version to current date (NOT RECOMMENDED).
|
|
|
|
|
|
**1. Adding pre-action**
|
|
|
|
|
|
Automatic build versioning should be done before build starts. This can be achieved by adding a script to build's pre-actions.
|
|
|
Select your scheme in Xcode, click `Edit Scheme...`, expand `Build` section, select `Pre-actions`, click `+` button and select `New runscript action`. Select your target at `Provide build settings from`.
|
|
|
|
|
|
![Screen_Shot_2017-04-20_at_13.51.19](/uploads/21e45b7b3cc92c589d69c88f762487ff/Screen_Shot_2017-04-20_at_13.51.19.png)
|
|
|
|
|
|
This will create a script, which will be run before each build. Next, add one of the following solutions.
|
|
|
|
|
|
**2. Autoincrementing**
|
|
|
|
|
|
This approach should be used whenever possible. The script could be found here:
|
|
|
[increment_build_version.sh](/uploads/59e015e3ead5b3d0c8b658c1498ff6c6/increment_build_version.sh)
|
|
|
|
|
|
Replace configuration names with ones you need and which are used for creating archives.
|
|
|
|
|
|
**3. Current date as build version**
|
|
|
|
|
|
This approach is not recommended because of possible conflicts with distribution software. This approach will set build version to current date. If current build version is already a current date, it will add counter suffix, like 12.12.2012-2 and will increment it each time. Also, this script is designed for 2 build configurations - ReleaseDev and ReleaseLive. If you're using only one, rename ReleaseDev to your configuration's name.
|
|
|
[date_versioning.sh](/uploads/f1bf2ae12ec1a2268d0e1ab400a6181e/date_versioning.sh)
|
|
|
|
|
|
**4. If something's gone wrong**
|
|
|
If it's not working for some reason, you need to debug it. The easiest way to debug a pre-action script is by adding the following code as the first line of your script:
|
|
|
|
|
|
```
|
|
|
exec > ~/Desktop/my_log_file.txt 2>&1
|
|
|
```
|
|
|
|
|
|
It will log all the output to `my_log_file.txt` on your desktop. If it's not helping - add `echo` commands to debug strings, values etc. |
|
|
\ No newline at end of file |