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