Android Play Console：当其他轨道的版本代码更高时，内部测试轨道不可用答案

【问题标题】：Android Play Console: internal test track is not usable when version code in other track is higherAndroid Play Console：当其他轨道的版本代码更高时，内部测试轨道不可用
【发布时间】：2022-04-14 00:58:39
【问题描述】：

问题Android play console: internal testing version, close testing ? how does it works?的答案是：

最终用户（或测试人员）无法选择他们想要的版本，他们将始终收到具有最高 versionCode 的 APK/AAB 符合条件。

但我想知道：如果我们在生产轨道上发布某些内容（即修补程序），当内部测试轨道被生产轨道覆盖时，我们如何继续使用内部测试轨道来开发新功能？

解决方法可能是：

在生产轨道上发布后，使用更高版本代码重新发布内部版本。
根本不使用内部测试轨道，而是为内部测试人员提供 apk。
发布单独的应用进行内部测试

但是所有这些都非常耗时，而且我认为没有工作流程可以对频繁更新的生产版本进行并行内部测试。

对此有何建议？

【问题讨论】：

标签： android google-play-console google-play-internal-testing

【解决方案1】：

我认为最好的方法是为每次构建不断增加版本代码，并始终上传具有更高版本代码的版本，并使用为您提供发布灵活性的版本控制策略。 不幸的是，Play 商店需要这个，但我不知道有什么办法。

例如：
您当前的生产版本的版本代码为 123，您正在测试下一个版本并希望分发以进行内部测试。您的下一个版本应该增加（例如版本代码 124），并发布到内部测试。完成测试并准备好发布后，您将版本 124 提升到生产环境并准备下一个版本进行内部测试（并将其版本代码增加到 125 等）。

这是一个人为的示例，在实际示例中版本控制策略可能会变得非常复杂（例如，如果您将修补程序版本直接发布到生产环境以修复关键错误），但这更多是与您的版本控制方式有关制定策略以及为每个版本增加的版本号。

再举一个真实世界的例子：

我们采用基于Semantic Versioning（黄金标准）major.minor.patch 作为版本名称的版本控制策略
我们使用MMMMmmpp 格式的匹配版本代码，其中我们使用 4 位数字表示主要版本 (M)，使用 2 位数字表示次要 (m) 和补丁 (p) 版本。
应用发布 v2.4.5 生成版本代码 00020405
每个正常版本都会增加次要版本，修补程序会增加补丁版本

【讨论】：

使用 MMMmmpp 格式的语义版本号作为版本代码是一种有趣的方法！这意味着可以减少升级版本的版本代码（即 2.0 (=00020001) 的发布修补程序，而 3.0-beta (=00030000) 仍然是最高版本代码，因此 beta 用户不会覆盖他们的 beta）。我不知道这是否有效，将尝试一下。谢谢！但仍然：在我的选项中，在自动更新方面，生产和测试轨道应该分离。但我猜这不太可能改变:)
您需要确保修补程序版本只增加 minor 或 patch 版本号并且不被视为主要版本（因为修补程序通常是对活动版本的修正，以修复意外行为）。仅将主要版本保留为重大的重大更改（如 SemVer 文档中的详细说明）在您的示例中，假设 v1.0(00010000) 是活动的生产版本，您希望您的修补程序类似于 v1.1(00010100)而不是 v2.0(00020000)，您的新 beta 版本可以是 v2.1(00020100) 或 v3.0(00030000) 或任何您喜欢的版本。