【问题标题】：What is a good iOS app versioning strategy when using TestFlight for internal testing?使用 TestFlight 进行内部测试时，什么是好的 iOS 应用版本控制策略？
【发布时间】：2016-01-13 07:13:22
【问题描述】：

我有一个 iOS 应用程序，它使用 semantic versioning 标记已发布的构建。我还使用 Apple 的 TestFlight 将内部构建推送给团队进行测试/QA。

推送内部构建需要将构建上传到 iTunes Connect。 iTunes Connect 的测试版本和发布版本之间没有区别，iTunes Connect 不允许覆盖以前上传的版本。所以每次我想推送一个新的内部测试版本时，我都必须提高版本号（嗯，补丁（X.X.X）号）。

这很好用，除了对我们的用户来说，我们的版本号看起来在更新之间跳了很多。例如，如果这是我们的构建历史：

v1.0.0
v1.0.1（测试中发现错误）
v1.0.2
v1.1.0（测试中发现错误）
v1.1.1（测试中发现错误）
v1.1.2

...那么用户只会看到粗体发布，而我们的发布历史看起来很奇怪：

v1.0.0
v1.0.2
v1.1.2

我认为避免这种情况的一个好方法是使用 beta 版本，例如 v1.1.0-beta 用于测试版本，但 iTunes Connect 拒绝任何不是 X.X.X 的版本字符串。

有没有办法继续使用 TestFlight 进行内部测试/QA 并避免向用户显示填补空白的版本历史记录？

【问题讨论】：

Xcode 有两个不同的地方放置版本号和内部版本号，那么为什么不保持版本号不变并编辑内部版本号呢？

标签： ios app-store testflight semantic-versioning

【解决方案1】：

我在构建版本中使用内部第 4 号，我相信 iTunes 仍然接受这一点。例如它可能是版本 1.0.0，但构建可能是 1.0.0.87，表示要测试的第 87 个内部构建。在 App 中显示时，您可以选择去掉最后一个数字，但人们通常不会在意。

我发现这在大多数地方都很容易理解和接受。

与版本号相比，内部版本号没有得到足够的信任。

【讨论】：

效果很好！何时增加版本号必须和何时增加内部版本号必须之间的区别是我一直在努力解决的问题。感谢您的澄清！
拥有 4 个组件是否合法？根据 Apple 的说法，“版本号和内部版本号最多可以包含三个以句点分隔的组件。” （来源：developer.apple.com/library/archive/technotes/tn2420/…）。
您可以拥有它们并查询它们，但它们不会显示在 App Store 上，但这使得它们非常适合附加内部版本号。
对于 iOS 应用程序的内部版本号不必跨版本唯一。因此，对于任何特定版本，构建号只能是 1、2、3...，下次版本递增时从 1 重新开始（Apple 将其称为版本发布序列）。
这在 2021 年仍然有效。任何关于 Android 与 iOS 应用程序保持同步的建议。在 Android 中，内部版本号必须是连续的单个数字。

【解决方案2】：

使用内部版本号。

只需按顺序增加内部版本号。

我们只使用一个简单的整数 523、524 等。

不要更改试飞的版本号，因为...

如果您更改实际版本号，您将毫无意义地触发该上传的另一个自动测试延迟！只需增加内部版本号。

【讨论】：

另外：对于 iOS 应用，内部版本号不必在不同版本之间唯一。因此，对于任何特定版本，构建号只能是 1、2、3...，下次版本递增时从 1 重新开始（Apple 将其称为版本发布序列）。

【解决方案3】：

基本上版本控制有以下规则。例如，如果现有版本是 v1.0.0，那么下一个版本将是：

v1.0.1 用于错误修复和细微更改。
v1.1.0 进行了重大更改，但应用仍然兼容旧版本。用户仍然可以运行旧版本的应用。
v2.0.0 进行重大更改，但应用程序不兼容
旧版本。用户无法运行旧版应用。
v1.0.0.1(beta) 用于内部测试

【讨论】：