Android Play Console：当其他轨道中的版本代码更高时，内部测试轨道无法使用
Android Play Console: internal test track is not usable when version code in other track is higher
问题中的答案是：
End users (or testers) cannot choose which version they want, they
will always receive the APK/AAB with the highest versionCode that they
are eligible for.
但我想知道：如果我们在生产轨道上发布某些东西，即修补程序，当它被生产轨道覆盖时，我们如何继续使用内部测试轨道来开发新功能？
解决方法可以是：
- 在生产轨道上发布后，重新发布具有更高版本代码的内部版本。
- 根本不使用内部测试轨道并为内部测试人员提供 apk。
- 发布一个单独的应用程序进行内部测试
但是所有这些都很耗时，而且对我来说，没有针对经常更新的生产版本进行并行内部测试的工作流程对我来说毫无意义。
对此有什么建议吗？
我认为最好的方法是为每个构建不断增加版本代码，并始终上传具有更高版本代码的版本，并使用为您提供发布灵活性的版本控制策略。
不幸的是，Play 商店需要这个，但我不知道有什么办法。
例如：
您当前的生产版本的版本代码为 123，您正在测试下一个版本并希望分发以进行内部测试。您的下一个版本应该递增（例如版本代码 124），并发布到内部测试。完成测试并准备好发布后，将版本 124 提升到生产环境并准备 next 版本进行内部测试（并将其版本代码增加到 125，等等）。
这是一个人为的示例，在 real-world 示例中版本控制策略可能会变得非常复杂（例如，如果您将修补程序版本直接发布到生产环境以修复关键错误），但这更值得关注以及您的版本控制策略是如何构建的，以及您为每个版本增加的版本号。
使用 real-world 示例更进一步：
- 我们采用基于 Semantic Versioning（黄金标准）
major.minor.patch 作为版本名称的版本控制策略
- 我们使用
MMMMmmpp 格式的匹配版本代码，其中我们使用 4 位数字表示主要版本 (M)，使用 2 位数字表示次要版本 (m) 和补丁 (p) 版本.
- 应用版本 v2.4.5 产生版本代码 00020405
- 每个正常版本都会增加次要版本，修补程序会增加补丁版本
问题
End users (or testers) cannot choose which version they want, they will always receive the APK/AAB with the highest versionCode that they are eligible for.
但我想知道：如果我们在生产轨道上发布某些东西，即修补程序，当它被生产轨道覆盖时，我们如何继续使用内部测试轨道来开发新功能？
解决方法可以是：
- 在生产轨道上发布后，重新发布具有更高版本代码的内部版本。
- 根本不使用内部测试轨道并为内部测试人员提供 apk。
- 发布一个单独的应用程序进行内部测试
但是所有这些都很耗时，而且对我来说，没有针对经常更新的生产版本进行并行内部测试的工作流程对我来说毫无意义。
对此有什么建议吗？
我认为最好的方法是为每个构建不断增加版本代码，并始终上传具有更高版本代码的版本，并使用为您提供发布灵活性的版本控制策略。 不幸的是，Play 商店需要这个，但我不知道有什么办法。
例如：
您当前的生产版本的版本代码为 123，您正在测试下一个版本并希望分发以进行内部测试。您的下一个版本应该递增（例如版本代码 124），并发布到内部测试。完成测试并准备好发布后，将版本 124 提升到生产环境并准备 next 版本进行内部测试（并将其版本代码增加到 125，等等）。
这是一个人为的示例，在 real-world 示例中版本控制策略可能会变得非常复杂（例如，如果您将修补程序版本直接发布到生产环境以修复关键错误），但这更值得关注以及您的版本控制策略是如何构建的，以及您为每个版本增加的版本号。
使用 real-world 示例更进一步：
- 我们采用基于 Semantic Versioning（黄金标准）
major.minor.patch作为版本名称的版本控制策略 - 我们使用
MMMMmmpp格式的匹配版本代码，其中我们使用 4 位数字表示主要版本 (M)，使用 2 位数字表示次要版本 (m) 和补丁 (p) 版本. - 应用版本 v2.4.5 产生版本代码 00020405
- 每个正常版本都会增加次要版本，修补程序会增加补丁版本