使用TestFlight进行内部测试时，什么是优秀的iOS应用版本控制策略？

Question

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

推送内部版本需要将版本上传到iTunes Connect。测试版本和发布版本与iTunes Connect没有区别，iTunes Connect不允许覆盖以前上传的版本。所以每次我想推出一个新的版本进行内部测试时，我必须对版本号进行修改（以及修补程序（X.X. X）number）。

这工作正常，除了我们的用户，它看起来像我们的版本号在更新之间跳来跳去。举例来说，如果这是我们的建设的历史：

• 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

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

有没有办法继续使用TestFlight进行内部测试/质量保证并避免向用户出现缺口填充版本历史记录？

Answer 1

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

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

版本号与版本号相比没有足够的功劳。