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.0v1.0.1 (bug was found in testing)v1.0.2v1.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.0v1.0.2v1.1.2I 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?
I use an internal 4th number in the build version, I believe iTunes still accepts this.
e.g. it might be version 1.0.0 but the build could be 1.0.0.87 indicating 87th internal build to test. You can choose to lop off the last number when displaying it in the App, but people do not usually care.
I have found this easy to understand and accepted in most places.
Build number as compared to version number is not given enough credit.