ios - TestFlight 应用内更新 : Version Number vs Build Number

Question

TestFlight 的应用内更新中版本号和内部版本号背后的逻辑是什么？ TF 声明内部版本号必须更大才能弹出并进行应用内更新，但我总是在增加/增加版本号时重置内部版本号。

如果我从 v1.0.0 (2) 更改 -> v1.0.1 (1)，是否允许进行应用内更新？或者我必须进行更新 v1.0.1 (3)。将内部版本号设置为 3 并不适合我的强制症，因为我很欣赏在我的内部版本历史记录中有合理的数字。我真的不想看到类似 v2.0.0 (547) 的内容。

我知道我可能会以更好的方式增加内部版本号和我的版本号 (v1.2.3 (123))，但存在潜在的问题，例如 v1 .2.34 (1234) 内部版本号高于 v1.3.0 (130)。

我正在向客户发布，所以我不太愿意对此进行测试，而且我使用的是公司开发人员帐户，因此构建随机测试应用程序可能看起来也不太好。希望有人可以简单地回答我的问题，我已经考虑过了所有这些。

我希望这个问题可以问。根据FAQ，我问程序员常用的软件工具应该没问题，但之前因为问TestFlight被骚扰过。

Answer 1

由于旧的 TestFlight 现在已被 iTC TestFlight 取代，我决定以合乎逻辑的方式管理我的版本和内部版本号。随着时间的推移，我发现最好的方法是像这样分解版本号:

版本号只是数字形式的产品历史记录。它通常被分解为 [major].[minor].[patch].[build] 其中内部版本号是可选的(尤其是在 iOS 中)。当主编号小于 1 并在 1.0.0.0 发布时，应用程序被视为 alpha 或 beta。

主要

主编号表示您的应用程序发生了巨大变化。当用户需要改变他们使用或考虑您的应用程序的方式时，增加这个数字是合适的。当此数字更新时，预计会删除已弃用的功能并且应用程序处于干净状态。次要和补丁号应重置为 0，构建应重置为 0 或 1。

• 完成 UI 大修
• 删除了以前的功能 - 未弃用
• 添加了重要的功能集 - 大到足以改变您的使用方式应用程序，否则使用顺序次要更新

轻微

次要编号表示您的应用程序发生了显着变化。当此数字更新时，某些功能可能会被弃用，以便在未来的主要更新中被删除。补丁号应重置为 0，build设置为 0 或 1。

• 添加了一个功能
• 引入了新的用户界面
• 经过大量补丁，所有补丁都绑定(bind)到一个超集中

补丁

补丁号表示您的应用程序中的小改动。当这个数字更新时，应用程序不一定会发布(假设专业至少为 1)并且功能不会被弃用。

• 内部版本号设置为 0 或 1。
• 错误修复
• 新功能
• 非面向用户的更改

构建

内部版本号表示开发者的内部版本索引。这个数字应该始终并且只随着每个开发人员进行的每个构建而增加。如果开发人员在同一个分支上工作，构建号应该随着提交而不是构建而增加。