时间：2015-10-15 01:12:34

标签： ios app-store testflight semantic-versioning

我有一个使用semantic versioning标记已发布版本的iOS应用。我还使用Apple的TestFlight将内部版本推送到团队进行测试/质量保证。

推送内部版本需要将版本上传到iTunes Connect。 iTunes Connect的测试版本和发布版本之间没有区别，iTunes Connect不允许覆盖以前上传的版本。因此，每当我想推出一个新的内部测试版本时，我都要打破版本号（好吧，补丁（X.X. X ））。

这样可以正常工作，但对于我们的用户来说，看起来我们的版本号在更新之间会大量跳转。例如，如果这是我们的构建历史记录：

...然后用户只看到大胆的版本，我们的发布历史看起来很奇怪：

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

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

答案 0 :(得分：6)

我在构建版本中使用内部第4个数字，我相信iTunes仍然接受这个。例如它可能是版本1.0.0，但构建可能是1.0.0.87，表示要测试的第87个内部构建。

，您可以选择在应用程序中显示最后一个号码时删除最后一个号码，但人们通常不在乎。

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

版本号与版本号相比没有给予足够的信誉。

答案 1 :(得分：1)

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

答案 2 :(得分：1)

使用内部版本号。

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

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

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

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