我知道您推荐 tests-passed，但我需要遵循 stable 分支，而 3.2.1 刚刚出现。但是我想知道为什么它显示为 3.2.1 +9。难道 stable 分支不应该（至少在发布后立即）是已发布的标签吗？
另外，为什么它显示 2 个版本，它将更新到哪个版本。我将获得哪个提交 ID？它将比较 Comparing e049f82681b0f719f740cb378564f03711ff1c08…6a0aa03aa285306560af679c84903be0d58a4203 · discourse/discourse (github.com) - 这是预期的吗？根据仪表板，e040f.. 是我当前的哈希。
仪表板的起始页尚未显示新版本，但是：
在我看来，v3.2.0 +9 中的 +9 意味着在当前版本（3.2.1 之前）之上还有几个提交。
v3.2.1 +5 意味着你可以更新到下一个版本 3.2.1，并且在此版本之上已经添加了几个提交。通常，我认为这些是从主分支回溯的重要修复。
我明白这可能一开始会让人感到困惑。我想知道这是否可以改进。
好的，所以 repository 列的意思是“你本地当前的安装”——这说得通，谢谢。我今天读了 3.2.1 的公告，所以我很惊讶已经有更多的提交了，但如果这是预期的，我也没问题。
您知道为什么主仪表板还没有显示该更新吗？（我明白如果它每天只刷新一次，但那时当我手动检查“更新”选项卡时，它也应该已经更新了。）
这是正确的，下一个版本标签是 3.2.1。我们在发布标签前漏掉了几个提交，所以它们被添加到了之后，因此有了 +5。通常我们会确保在发布标签前进行回溯移植，但这次我们漏掉了。这种情况时有发生。
请注意，这里的 +5 提交修复了以下问题：
guidelines_topic.body 的翻译@ecki，更新后您将获得的提交 ID 是 6a0aa03，其中包含上述修复。
“更新”屏幕来自 docker manager 插件，主仪表板是核心的检查，每天只发生一次。两者不通信，因此存在差异。（不过，这是一个好点子，如果它们能够通信就好了。）
非常有帮助，非常感谢。
既然我们谈论到这个话题，是否有机制来决定何时进行重建，例如紧急的基础/数据库/数据容器更新，或者这是否从未在前台更新仪表板中发出信号？
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.