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) {1}}。
我正在向客户发布，所以我很难测试这个，而且我正在使用公司开发者帐户，因此构建随机测试应用程序可能看起来也不会很好。希望有人可以轻松回答我的询问，并且我已经推翻了所有这些。
我希望这个问题可以问。根据常见问题解答，我应该可以询问software tools commonly used by programmers，但我之前因为询问TestFlight而受到骚扰。
答案 0 :(得分：3)
由于旧的TestFlight现在被iTC TestFlight取代，我决定以合理的方式管理我的版本和构建数字。随着时间的推移，我发现最有效的方法是分解版本号：
版本号只是数字形式的产品历史记录。它通常被分解为[major]。[minor]。[patch]。[build]其中构建号是可选的（特别是在iOS中）。应用程序被视为alpha或beta，而主要数字小于1，并在1.0.0.0发布。
<强>主要
主要数字表示您的申请发生了巨大变化。当用户需要更改他们使用或考虑您的应用程序的方式时，增加此数字是合适的。 当此数字更新时，预计将弃用已弃用的功能并且应用程序处于干净状态。次要和补丁号应重置为0，构建应重置为0或1。
<强>次要
次要编号表示您的申请发生了明显变化。 当此数字更新时，某些功能可能会被弃用，暂存以便在将来的主要更新中被删除。补丁号应重置为0，并将build设置为0或1。
<强>修补程序
补丁号表示您的应用程序中的小变化。 当此数字更新时，应用程序不一定会被释放（假设主要部分至少为1），并且不会弃用功能。
<强>构建
内部版本号表示开发人员的构建索引。 这个数字应该始终只在每个开发人员制作的每个构建时增加。如果开发人员在同一个分支上工作，那么构建号应该以提交而不是构建来增加。
答案 1 :(得分：1)
我只在更改功能/主要错误时更改版本。当我积极参与试飞时，我每次归档时都只会更改内部版本号。
所以它看起来像v1.0（1），然后是v1.0（2），然后是v1.0（3）
当我认为应用程序很好去商店，下一轮开发时，它转到v1.1（4），v1.1（5），v1.1（6）等等等等等等
这至少是我的模式。我是一个单一的开发商店，但无论如何工作。
答案 2 :(得分：0)
build number可以是%d.%d.%d格式。例如，120.3.60。
因此，我将一些信息放入build number。
因此，我制作的内部版本号可能是这种格式（GitTag计数，内部版本，Jenkins buildNumber），例如：120.3.60。 （GitTag计数：120，Jenkins的buildNumber：60，内部版本：3）。
可以通过shell脚本生成内部版本号信息。