12

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

推送内部构建需要将构建上传到 iTunes Connect。iTunes Connect 的测试版本和发布版本之间没有区别，iTunes Connect 不允许覆盖以前上传的版本。所以每次我想为内部测试推送一个新版本时，我都必须增加版本号（嗯，补丁（XX 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 并避免向用户显示填补空白的版本历史记录？

4

3 回答 3

12

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

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

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

于 2015-10-15T01:17:37.413 回答
2

使用内部版本号。

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

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

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

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

于 2021-03-03T11:59:44.233 回答
1

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

  • v1.0。1用于错误修复和微小更改。
  • v1。1 .0 进行重大更改，但该应用程序仍与旧版本兼容。用户仍然可以运行旧版本的应用程序。
  • v 2 .0.0 用于重大更改，但该应用程序与 旧版本不兼容。
    用户无法运行旧版本的应用程序。
  • v1.0.0.1(beta) 用于内部测试
于 2021-03-03T11:55:45.817 回答