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

【问题标题】：TestFlight In-App Updates: Version Number vs Build NumberTestFlight 应用内更新：版本号与内部版本号
【发布时间】：2014-02-05 05:00:27
【问题描述】：

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，我应该可以问software tools commonly used by programmers，但我之前因为问过TestFlight而受到骚扰。

【问题讨论】：

我认为你只需要克服你的“强迫症”。我曾经这样想，但试飞改变了我的思路。所以版本号是面向市场的（1、1.1、1.0.1 等），并且构建是连续的。不要与工具作斗争。

【解决方案1】：

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

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

专业

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

轻微

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

补丁

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

构建

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

【讨论】：

【解决方案2】：

我仅在进行功能/主要错误更改时更改版本。当我积极进行试飞时，我只会在每次存档时更改内部版本号。

所以它看起来像 v1.0 (1)，然后是 v1.0 (2)，然后是 v1.0 (3)

当我认为应用程序好去商店时，下一轮开发，它去v1.1（4），v1.1（5），v1.1（6）等等等等.

这至少是我的模式。我是一家开发商店，所以不管怎样都行。

【讨论】：

【解决方案3】：

build number 可以是 %d.%d.%d 格式。例如，120.3.60。

所以，我将一些信息放入build number。

所以，我制作的版本号可能是这种格式（GitTag 计数、内部版本、Jenkins 版本号），例如：120.3.60。（GitTag 计数：120，Jenkins 的 buildNumber：60，内部版本：3）。

内部版本号信息可以由shell脚本生成。

【讨论】：