Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G Guides
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ios-general
  • Guides
  • Wiki
  • versioning rules

Last edited by Artem Kalmykov May 09, 2017
Page history

versioning rules

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

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

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

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

Pre-build script has reference to ${INFOPLIST_FILE} variable, which should return full path to info.plist file. Sometimes it doesn't, in this case change it to ${PROJECT_DIR}/${INFOPLIST_FILE}

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.

Clone repository
  • Swift Code Style
  • automated slack builds
  • continuous integration
  • Home
  • jenkins auto build
  • shared localization
  • versioning rules