用 Stream 预览 RHEL 次版本

预览在这里指一件事：在 RHEL 次版本正式发布之前，用 CentOS Stream 提前观察即将进入 RHEL 的变化。这个用法能不能成立，取决于官方对 Stream 的定位，而不是「它一定等于 RHEL 下一版」这类推断。本页只讲定位依据、隔离要求、上报渠道与对齐检查。

官方定位：紧跟 RHEL 开发之前的持续交付发行版

官方下载页对 CentOS Stream 的定位原文是：持续交付（continuously delivered）的发行版，紧跟 RHEL 开发之前（tracks just ahead of RHEL development），在 Fedora Linux 与 RHEL 之间定位为 midstream；对希望在 RHEL 生态中参与协作的人，官方称它是「可靠的创新平台」。以上逐字来自该页首段，

注意

这里刻意只复述原文用词：官方用的是「紧跟 RHEL 开发之前」与「midstream」，本页不据此推断上游或下游结论，也不承诺 Stream 上的行为等于某个具体 RHEL 次版本的行为。

预览流程设计

预览环境的价值来自提前看到变化，所以流程要围绕差异设计，而不是把 Stream 装成第二套生产：

• 先定观察对象：要观察的是某个具体能力（内核行为、运行时、依赖链），还是一次整体升级适配；对象不同，验证清单不同。
• 按版本线建立基线：同一批测试在目标版本线与对照版本线上各跑一遍，结论才有比较意义。
• 把发现写成可复现记录：版本线、时间、复现步骤、现象、影响面，五项齐全才算一条可用记录。
• 明确谁来判定：预览结论由谁签字、满足什么条件才允许推进到生产变更，事先写清楚。

警告

本页给的是流程骨架，不是验收标准。每一项验证做到什么程度，取决于你自己的业务容忍度与合规要求。

与生产隔离

预览环境的默认前提是不承载生产流量、不接入生产凭据：

1. 独立环境：单独的主机或集群，独立网络段，不与生产共享存储与目录服务；
2. 独立账号：不复用生产账号体系与密钥，避免测试动作沿着凭据扩散；
3. 独立数据：只用脱敏或合成数据，不要在预览环境里放生产数据副本；
4. 可随时重建：环境要能一键推倒重建，这是它敢承接「会出问题的验证」的前提。

危险

不要把预览环境当生产用，也不要把生产环境拿来做预览验证。官方定位说的是参与协作与创新的窗口，不是兼容性保证；用 Stream 上的一次观察结果直接决定生产变更，属于超出证据范围的做法。

问题上报路径：先用官方邮件列表

官方邮件列表服务入口是 lists.centos.org：本轮核对时该页按名称列出 devel、announce、discuss、arm-dev、automotive-sig 以及若干语言讨论列表等条目，并给出每个列表的说明与近 30 天活跃度，其中 devel 显示 5 位参与者、6 个讨论。

列表只提供渠道，不提供响应时限。用它做上报时，建议先做三件事：

• 找对列表：先读列表自身的说明再决定发到哪里，发错列表最常见的结果就是被转到另一个列表；
• 把记录写成最小可复现：环境、版本线、复现步骤、期望与实际结果、相关日志片段；
• 保留原始记录：本地存档一份，便于后续在讨论线程里补充证据。

警告

本轮只核对了「官方邮件列表入口存在并列出各列表」这一件事。各列表的用途与活跃度以该页当前显示为准；本页不把任何列表描述为唯一的官方支持渠道。

版本对齐检查

用 Stream 做预览，最容易出的错是比错了对象：拿 Stream 的当前状态去推断某个已发布的 RHEL 次版本，或者反过来。开始前先确认四件事：

• 目标版本线：本次预览对应哪条版本线，写进记录，见 CentOS Stream 版本与支持；
• 内容范围：内容取自哪套仓库、是否启用了额外内容集，见 CentOS Stream 仓库与滚动内容；
• 对照基线：拿什么做对照，对照环境的版本线是否与目标同步；
• 滚动特性：Stream 的内容是滚动的，同一条版本线的两个时间点并不等价，记录必须带时间。

相关页

• CentOS Stream 版本与支持 — 版本线与时间口径
• CentOS Stream 仓库与滚动内容 — 内容范围与滚动特性
• 安装 CentOS Stream — 预览环境的搭建起点
• CentOS Stream 运维基线 — 把预览环境纳入日常维护
• CentOS Stream 常见问题 — 定位相关的常见疑问
• 官方：CentOS Stream 下载页（定位原文出处）、CentOS 邮件列表（渠道入口）