TestFlight 应用内更新：版本号与内部版本号

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).

我正在向客户发布，所以我对测试这个感到不舒服，而且我使用的是公司开发人员帐户，因此构建随机测试应用程序可能看起来也不太好。希望有人可以对我的询问有一个简单的答案，我已经考虑了所有这些。

我希望这个问题可以问。根据常见问题解答，我应该可以询问有关 的问题software tools commonly used by programmers，但我之前曾因询问有关 TestFlight 的问题而受到骚扰。

Answer 1

由于旧的 TestFlight 现在已被 iTC TestFlight 取代，我决定以合乎逻辑的方式管理我的版本和内部版本号。随着时间的推移，我发现最有效的方法是分解版本号，如下所示：

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

主要的

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

• 完成 UI 改造
• 删除了以前的功能 - 未弃用
• 添加了重要的功能集 - 足够大以改变应用程序的使用，否则使用连续的小更新

次要的

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

• 添加了一项功能
• 引入了新的用户界面
• 经过大量补丁后，所有补丁都整合为一个超集

修补

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

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

建造

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