我想知道我们是否可以为插件提供版本号，以便插件可以列出它兼容的最低和最高 Discourse 版本。
这样我们就不会遇到插件更新了，但我们的 Discourse 版本落后了，然后导致整个站点崩溃的情况。
TC 中有两种广泛的插件和 TC：
- 官方
- 第三方
官方插件已经维护了兼容性，如果它们不兼容，通常会有带薪开发者在几天内修复。
第三方插件
维护者要保持兼容性已经够难了，更不用说跟踪它们是否兼容了。
实际上只有两个版本是实际可维护的：
- 最新
stable - 最新
tests-passed
您可以使用固定系统 (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) 来固定 stable 版本。如果能以某种方式显示出来以明确表示兼容性，那会很好，但这并不意味着如果没有固定，插件就 不 兼容。
与最新版本的兼容性可以通过 GitHub CI 上的绿色勾号来显示。
这依赖于两件事：
- 完善的 CI 设置（最好基于 Discourse 插件标准）
- 非常高的测试覆盖率
后者对于免费做事的第三方维护者来说要求很高。
对于非官方插件，您的功能请求归结为对第三方插件提供体面的资金支持。
作为一名经验丰富的插件作者，我可以告诉您，为第三方插件提供资金几乎是不可能的。
我的插件仍然有效的原因是：
- 我自己使用它们
- 作为在生态系统中维护声誉的一种方式。
这对我有价值，但也有其局限性。
我认为在 Discourse 生态系统中，第三方插件开发几乎是 
（死亡）的，只有极少数开发者能够跟上核心开发的高速迭代。
其他例外：
- Communiteq 等主要托管商使用的插件 - 也许他们有看法 - 但即使是他们也必须专注于大多数客户想要的东西，并且他们的资源也会有限。
- 带有订阅系统的 Custom Wizard 和 Events 插件 - 您可以再次从 Angus 那里了解其发展方向。
总结
鉴于您实际上只能依赖官方插件的兼容性（以及可能来自像我或 Communiteq 这样活跃开发者的少数其他插件），我建议您只专注于使用 official 插件，对于这些插件，我认为您的功能请求是多余的，因为已经有流程来跟踪核心。
7 个赞
我不确定如何为插件定义最大兼容版本。一个简单的插件可能可以说它至少支持到 4.0 版本，当 4.0 发布时，它可能仍然有效，因为 CDCK 没有引入任何破坏性更改。
但也许这个简单的插件使用了 CDCK 在 3.8 版本中弃用并在 3.10 版本中删除的某些内容……要考虑到这一点相当困难。
因为你不能。
一旦下一个提交发布，它就会过时。
但是很简单：
- 在 CI 中对核心的每次新提交运行详尽的（95% 覆盖率）插件测试（后端和系统最低）
然后安装前检查绿色勾号。
我一直在尝试这个，并在 Github 上找到了一个解决方案。
因此，仅仅一个最近的 CI 作业的绿色勾号是不够的，因为最近可能会发生一些变化，从而破坏插件。基本上，当 Discourse 更新分支时，您需要重新运行 CI 作业。
在我的 示例存储库 中，我找到了一个有效的解决方案。它基本上是一个计划工作流，用于检查 Discourse 存储库的重要分支，以查看是否有更改，如果有，它将触发正常的 CI 工作流，该工作流应运行测试套件。在您的自述文件中，您可以放置一些徽章来显示 CI 工作流如何针对最近的更改运行。
监控工作流 在几秒钟内运行。因此，当计划运行时，它只会消耗 1 分钟的 Github 操作时间。
显然，整个设置的可靠性取决于插件/主题组件开发人员创建良好测试套件的努力。
您仍然存在用户体验问题，即从 Discourse 的“更新”页面中，您不知道最近的 CI 作业是否因特定版本而失败。
因此，除了拥有一个在 Discourse 分支更改时重建插件的监控工作流之外，您还需要创建一个记录结果（通过/失败）的构建工件。在您的插件元数据中，您应该能够指向此工件，并且 Discourse 应该检索此工件以在更新界面中显示兼容性/结果。
这不是一个万无一失的构造，但它是有用的。
这就是我写“在 CI 中对核心的每一次新提交时”的原因 
我们曾经在 Pavilion 上有一个仪表板，它能做到所有这些。