ios - 使用 TestFlight 进行内部测试时，什么是好的 iOS 应用程序版本控制策略？

Question

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

推送内部构建需要将构建上传到 iTunes Connect。 iTunes Connect 的测试版本和发布版本之间没有区别，并且 iTunes Connect 不允许覆盖以前上传的版本。因此，每次我想为内部测试推送一个新版本时，我都必须修改版本号(好吧，补丁 (X.X.X) 号)。

这工作正常，除了我们的用户看起来我们的版本号在更新之间跳跃了很多。例如，如果这是我们的构建历史:

• v1.0.0
• v1.0.1(测试中发现bug)
• v1.0.2
• v1.1.0(测试中发现bug)
• v1.1.1(测试中发现bug)
• v1.1.2

...那么用户只会看到大胆的发布，而我们的发布历史看起来很奇怪:

• v1.0.0
• v1.0.2
• v1.1.2

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

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

Answer 1

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

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

内部版本号与版本号相比没有给予足够的信用。