问TestFlight应用内更新:版本号与内部版本号

EN

由于旧的TestFlight现在被iTC TestFlight取代，我决定以一种合理的方式管理我的版本并构建数字。随着时间的推移，我发现最有效的方法是像这样分解版本号：

版本号只是一种数字形式的产品历史。它通常被分解为major.minor.patch.build，其中内部版本号是可选的(特别是在iOS中)。当主要编号小于1且发布版本为1.0.0.0时，应用程序被认为是alpha或beta。

主要

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

• Complete UI overhaul
• Dropped以前的功能-没有添加deprecated
• Significant功能集-大到足以改变应用程序的使用，否则使用顺序的次要更新

次要

次要编号表示应用程序中的明显变化。当这个数字更新时，一些功能可能会被弃用，准备在未来的主要更新中删除。补丁编号应重置为0，内部版本应设置为0或1。

• 添加了feature
• Introduced新的UI
• ，在此之前，大量补丁程序都绑定到

超集

补丁

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

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

Build

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

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

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

当我认为应用程序可以去商店的时候，下一轮开发，它就会进入v1.1 (4)，v1.1 (5)，v1.1 (6)，以此类推。

至少这是我的模式。我是一个单一的开发商店，所以无论如何工作。

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

因此，我在build number中输入了一些信息。

• Git标签计数

如果存储库中有10个标记，则最新编号将为10.

• Jenkins's内部版本号

我认为这更有意义。它可以帮助开发人员在jenkins的history.

• A内部版本中找到项目版本，它是项目的内部版本号。一般来说，对于我目前工作的公司，它是一个十进制数。

因此，我生成的内部版本号可能是这样的格式(GitTag计数，内部版本，Jenkins buildNumber)，例如：120.3.60。(GitTag计数: 120，詹金斯的buildNumber: 60，内部版本: 3)。

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