TestFlight应用内更新：版本号与构建号

Question

4

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

如果我从v1.0.0(2) 切换到 v1.0.1(1)，那么是否可以进行应用内更新？或者，我必须使更新版本为v1.0.1(3)。将构建号设置为3并不符合我的OCD，我希望我的构建历史记录中有合理的数字。我真的不想看到类似于v2.0.0(547)这样的东西。

我知道我可能可以以更好的方式（v1.2.3（123））同时增加版本号和构建号，但也存在潜在的问题，例如v1.2.34（1234）的构建号高于v1.3.0（130）。

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

我希望这个问题可以问。根据FAQ的说明，我应该可以询问“程序员通常使用的软件工具”，但我曾因为询问TestFlight而受到骚扰。

- RileyE

1

我认为你只需要克服你的“OCD”（强迫症）。我曾经也这样想，但是测试飞行改变了我的思路。因此版本号面向市场（1、1.1、1.0.1等），而构建则是顺序的。不要与工具对抗。 - bpapa

3个回答

3

我只在进行功能/重大错误更改时才更改版本。当我正在积极地进行测试时，每次归档时我只更改构建号。

因此，它将看起来像v1.0（1），然后是v1.0（2），然后是v1.0（3）。

当我认为应用程序准备好发布到商店时，下一轮开发将变成v1.1（4），v1.1（5），v1.1（6）等等。

这至少是我的模式。虽然我是一个单独的开发人员，但任何有效的方法都可以。

- Erick Smith

0

build number 可以采用 %d.%d.%d 格式，例如：120.3.60。

因此，我将一些信息放入了 build number 中。

因此，我制作的构建号可能采用这种格式（GitTag 计数、内部版本、Jenkins 构建编号），例如：120.3.60。（GitTag 计数：120，Jenkins 的构建编号：60，内部版本：3）。

构建号信息可以通过 shell 脚本生成。

- AechoLiu

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- RileyE · Accepted Answer

由于旧版TestFlight现已被iTC TestFlight取代，我决定以一种逻辑方式管理我的版本和构建号。随着时间的推移，我发现最好的方法是将版本号分解如下：

版本号只是您的产品历史的数字表示形式。通常将其拆分为[主要].[次要].[补丁].[构建]，其中构建号是可选的（特别是在iOS中）。应用程序在主要号小于1且发布于1.0.0.0时被视为alpha或beta。

主要：主要号表示应用程序的重大更改。当用户需要更改使用或思考应用程序的方式时，适当增加此数字。更新此数字时，预计弃用的功能将被删除，并且应用程序处于干净状态。次要和修补程序编号应重置为0，而构建应重置为0或1。

次要：次要号表示应用程序的显着更改。当此数字更新时，一些功能可能会被弃用，为将来的重大更新做铺垫。补丁号应重置为0，构建设置为0或1。

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

构建号表示开发人员的构建索引。每个开发人员制作的每个构建都应增加此数字。如果开发人员正在同一分支上工作，则构建号应随提交而不是随构建递增。