I have an iOS app that uses semantic versioning to tag shipped builds. I'm also using Apple's TestFlight to push internal builds to the team for testing/QA.
Pushing an internal build requires uploading a build to iTunes Connect. There's no distinction between a test build and release build to iTunes Connect, and iTunes Connect does not allow overwriting previously uploaded versions. So every time I want to push a new build for internal testing, I have to bump the version number (well, the patch (X.X.X) number).
This works fine, except to our users it looks like our version numbers jump around a lot in between updates. For instance, if this is our build history:
v1.0.0
v1.0.1
(bug was found in testing)v1.0.2
v1.1.0
(bug was found in testing)v1.1.1
(bug was found in testing)v1.1.2
...then the users are only seeing the bold releases, and our release history looks odd:
v1.0.0
v1.0.2
v1.1.2
I thought a good way to avoid this is to use beta versions, like v1.1.0-beta
for the test builds, but iTunes Connect rejects any version strings that aren't X.X.X
.
Is there a way to continue using TestFlight for internal testing/QA and avoid the appearance of a gap-filled version history to users?