每周更新一次的 Jenkins 版本为需要它们的用户和插件开发人员快速提供错误修复和新功能。 但是对于更保守的用户来说,最好坚持使用不经常更改的发行版且只接收重要的错误修复,即使这样的发行版功能落后。 有几家公司为了稳定和内部自定义而维护他们自己的私有 Jenkins 分支。 我们鼓励每个人将部分工作转移到此发行路线 。
这称为 Jenkins 长期支持版本,即 LTS。 这个概念与 Ubuntu 中的 LTS 概念非常相似,我们的模型如下所述。
每隔12周,社区将以协商一致的方式选择一个相对较新的版本,并将其标记为下一个“稳定但较旧”的版本线的基线。 假设这是版本 X 。 我们将 X 为基础创建一个分支用来生成如 X.1, X.2, 和 X.3 的稳定但是较旧的版本。 对于此分支的更改将仅限于在主干上经过“战斗测试”的最好的 Bug 解决方案移植回此版本 — 意味着这些提交在主线发行版上作为一部分已超过一周以上。 在四周的周期中发布的基线有3个次要版本。 发布的候选版本会在次要发布前两周发布。
下表显示了12周周期内的发行版发布日期:
周数 | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 | 24 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
发行版 | W.3 | X.1 RC | X.1 | X.2 RC | X.2 | X.3 RC | X.3 | Y.1 RC | Y.1 | Y.2 RC | Y.2 | Y.3 RC | Y.3 |
基线选择 | X chosen | Y chosen | Z chosen |
该周期从第0周选择 LTS 基线开始。 然后有两周的后向移植时间,紧跟着两周用来测试发行候选版本来产生 X.1 版本。 后向移植和 RC 测试重复两次, 产生 X.2 和 X.3 版本。 给定基线的循环结束后立即开始新的循环。
选择基线发行版通常持续2-5周,所以 X.1 LTS 发行版在其基线发行6-9周后发布。
查看 活动日历 来了解不久后特定的 LTS RC /发布日期。
任何用户都可以使用 lts-candidate 标签提出修复错误并后向移植到 LTS 版本中。 申请后向移植的人使用 此查询 来列出解决问题后需要注意的问题。
除了上面提到的模型,申请后向移植的人可采用一些主观选项 — 如修复是否简单且安全地后向移植,修复的可信度,问题的影响/重要性,距离后向移植窗口关闭的时间等等。
如果后向移植了,则应该使用像 2.46.2-fixed
这样的标签来告知用户它将要进入的 LTS 版本。
如果后向移植被拒绝了, 使用像 2.46.2-rejected
这样的标签表示此项不会被移植到指定的版本 — 但它可能在后续的 LTS 版本中被使用。
由于 Jenkins 储存内部数据的方式, 用户通常可以升级到较新的版本, 而不会降级到旧版本。 在 LTS 的上下文中, 基线 总是其他哪些发行版中 Jenkins 可以迁移的决定性因素。
确保您迁移到的每周更新版本已在您使用的的 LTS 版本之后发布。
虽然几乎比 LTS 基线发行版更新的每周更新版是兼容的,但 LTS 中的重要性修复(如安全性修复)可能不会出现在较旧的每周更新版中.