suse是linux的一个发行版本,SUSE 如何构建其 Enterprise Linux 发行版–第 4 部分

Share

在本系列文章中，我们将深入探讨 SUSE Linux Enterprise 产品开发，这里是其中的第四篇博客。您将通过这些文章获得 SUSE 和 SLE 产品的第一手概况，了解工程团队如何应对日新月异的开源项目、来自客户和合作伙伴的新需求，以及与业务相关的限制等。

SUSE 如何构建其 Enterprise Linux 发行版：

无论您是 SUSE 的长期客户、新客户、SUSE 的合作伙伴，还是 OpenSUSE 的粉丝或开源的狂热爱好者，我们都希望这些博客在让您觉得有趣的同时也能够让您获得丰富的内容。

让我们回顾一下到目前为止，我们是如何规划SLE 12 和 SLE 15 代码流的发行周期的。

SLE 从 SLE12 到 SLE15SP2 版本的完整表格(本文发布时，SLE15SP2 仍处于测试阶段)。

如果您想知道为什么 SLE 15 SP2 只有 3 个公开预发行版，请阅读 “预发行版的更改”部分。

发行周期和 Tick-Tock 模式

如您所见，从SUSE Linux Enterprise 12 开始，我们每年都会定期发布一个 Service Pack。对于 SUSE Linux Enterprise 15 也同样如此。由于许多客户和合作伙伴都要求拥有可预测性，所以我们提供了路线图。提醒大家的是，确切的 FCS 日期可在 https://www.suse.com/lifecycle/ 上找到。

上表所示的另一个重要方面是，SLE 使用的是，我们通常称之为“整合/刷新”模式。

这是什么意思？简单地说：

Tick –奇数版本–整合

维护更新中的错误/安全修复，

现有功能的改进，

SLE 15 与 SLE 12 之间的对等功能

选定的新功能，

Tock – 偶数版本 – 刷新

Tick 发行中的所有内容

内核版本差异

堆栈升级

Tick-Tock 模式在代码流的整个发布周期中是一致的。代码流的最后一个 Service Pack 一定是“整合 Service Pack”，因为我们的“Service Pack 模式”其目的就是确保稳定性和稳定度，这对需要迁移到下一个主要版本的客户而言尤为重要，为此，我们需要打下一个坚实的基础。

正因为这样，SLE 12 的最后一个 Service Pack，即 SLE12 SP5，是一个“整合 Service Pack”。

最后但同样重要的一点是，Tick-Tock 模式是一项原则，即 SLE 团队的一个“指南”，对于我们的用户而言，应被视为一个“主题”。

举一个具体的例子：我们必须为特定的Service Pack 选择一个特定的 Linux 内核版本。例如，SLE 12 SP1 被标记为“整合”Kernel 3.12.49(在 FCS 处)，SLE 12 SP2 被标记为“刷新”内核 4.4.21(在 FCS 处)。因此很明显，我们使用了 Refresh Service Pack 来跳转到一个主要的 Linux 内核新版本。

然而：

SLE 12 SP1(内核 12.49)是否缺少一些由上游内核版本 4.4 引入的一些驱动程序支持？

否。我们的工作不仅是确保使用稳定的 Linux 内核，还要让我们的产品能够被客户可能已经购买的新硬件所用。因此，我们将根据客户和合作伙伴的要求将Linux 内核功能“”到我们的 Linux 内核版本中。

SLE 12 SP2 是否支持上游内核版本 4 引入的所有最新功能？

否。并不是所有这些功能都符合我们的质量标准，因此我们将其标记为技术预览 (Technology Preview)，使其可用于测试。下一个 Service Pack，SLE 12 SP3(标记为“整合”)可能会充分支持这些功能。

这只是众多例子中的两个，说明灵活性是关键。SUSE 和我们的用户都将始终重视稳定性和增强性，因此 Tick-Tock 模式的应用绝不是非黑即白。

因此，我们仍建议您阅读Service Pack*的功能和技术预览，这些更改可能会与“整合”和“刷新”Service Pack 一起提供。

*当我们弃用一项功能时，会在弃用生效之前发布一个 Service Pack。

并行开发与维护

在 SLES 15 SP1 发行说明的“支持与生命周期”部分，如下所述：“[…]SUSE Linux Enterprise Server 15 的生命周期为 13 年，其中 10 年的常规支持和 3 年的扩展支持。当前版本 (SP1) 将在 SUSE Linux Enterprise Server 15 SP2 发布后的 6 个月内得到全面维护和支持。[…]”因此，当 SP1 和 SP2 都受支持时，将有 6 个月的重叠期。我们的工程师努力维护和开发的是软件包和/或技术，而不是产品的特定版本，这意味着任何特定的工程师都必须在多个 Service Pack 中并行维护软件包。

除此之外，在 2019 年，当 SLE 12 SP5 和 SLE 15 SP1 都处于开发阶段时，SLE 12 SP4 和 SLE 15 同时得到了支持和错误修复。因此，我们的 SLE 工程师必须继续维护他们发布的材料，同时处理即将发布的版本。

实际上，在开源项目中常用的开发和维护的通用术语是由通用代码分支模式派生而来的：

“Dev”分支，所有激动人心的新开发都在这里进行。通常根本不受支持。

“Stable”分支，通常只接收错误和安全修复。支持有限的时间。

“Long Term”分支，只考虑重要和关键的修复。延长旧版本的支持时间。

从理论上讲，这是一个简单的模式，它为每个工程师和用户提供了一个框架，告诉他们对任何一个特定分支应该期望什么，应该交付什么。

当然，在某个时间点，“Dev”分支可能会被“冻结”，成为一个新的 Major Stable 分支。

SLE 也采用了类似的方法，只是更加复杂，因为我们有两个主要版本，每个版本都有各自的“开发还有最后一个需要考虑的分支，当然就是“上游”分支：openSUSE。

但目前能确定的是，当我们并行支持两个主要版本((开发 + 通用支持 + LTSS)* 2 + 上游分支)时，SLE 共有 7 个分支。

这在现实生活中是如何运作的呢？我们将在以后的博客中对此进行解释。

推荐阅读：

Share

(Visited 1 times, 1 visits today)