长期支持发行版路线

每周更新一次的 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 基线发行版更新的每周更新版是兼容的,但 LTS 中的重要性修复(如安全性修复)可能不会出现在较旧的每周更新版中.

从每周更新版切换到 LTS (长期支持版)

确保您要迁移到的 LTS 基线版本比您的每周更新版新(通过比较数字)。 例如,如果您使用的是 Jenkins 2.5,2.18或者2.46,则可以在不出现重大问题的情况下升级到Jenkins LTS 2.46.X. 但是,如果你使用的是 Jenkins 2.47 或 Jenkins 2.56, 您可能在降级到 Jenkins LTS 2.46.X 时出现问题, 即使 LTS 版本比您正在使用的每周更新版本更晚发布。

切换更新站点

Jenkins 项目使用多个升级站点来通知 Jenkins 和插件可用的升级。 由于 Jenkins 在请求数据的时候发送它的当前版本信息,相同的 URL 可以被所有 Jenkins 发行版使用,并将始终提供最合适的版本信息。 例如, 在运行 LTS 发行版时只会提供能够升级的 Jenkins LTS 版本。

在发行路线之间切换完成后, 建议通过点击插件管理器中的“立即检查”按钮来更新在 Jenkins 中缓存的更新站点元数据( 此处) 有更多说明。 否则,Jenkins 可能会提供与安装版本不兼容的升级或插件安装。