从源码到镜像，openEuler 是怎么“生出来”的？| 发布流程一文搞懂！

前阵子朋友在群里问我一句话：“你说 openEuler 一个版本是怎么发布出来的？是不是大家打个 tag，然后编译一下就完了？”

我差点一口咖啡喷出来。

你以为开源操作系统发布跟煮泡面似的？三分钟就搞定？

我只能说：兄弟，这锅面，不但要自己种麦、磨粉、和面、拉条子，还得自己烧水、调味、洗碗……

所以今天，咱们就来一波“揭秘”——openEuler 的发布流程，真不是你想的那么简单。

一、openEuler 发布，不是拍脑袋说了算，而是“协作+制度”的产物

先明确一件事：openEuler 不是一个小团队关起门来自嗨的项目，而是由 开放原子开源基金会托管、数百个组织参与、全球开发者共建 的大型社区操作系统。

这意味着：

• 每一次版本发布，背后是数百个仓库、上万个软件包的组合拳；
• 每一个流程节点，都有社区 SIG（Special Interest Group）牵头、协同、评审、验证；
• 最终发布的产物，不止是一个 ISO 镜像，而是包含 SDK、容器镜像、构建工具链、文档、仓库元数据等 一整套基础设施交付物。

一句话：这是工业级流水线，不是实验室 demo。

二、发布节奏：一年两次大版本，稳定之上再迭代

openEuler 每年会发布 两个正式版本，一般是：

• 3月发布春季版本（适配创新硬件和特性，探索性更强）
• 9月发布长期支持版本（比如 LTS，稳定性优先）

另外还有：

• 月度社区版本 Preview：类似“夜间构建版”，方便开发者提前测试；
• 安全/稳定更新流（比如 openEuler 22.03-LTS-SP3），每季度滚动补丁。

是不是感觉很像 Android 的发布节奏？没错，开源操作系统，也得有产品节奏感！

三、从代码到系统：openEuler 发布流程核心 7 步走

第 1 步：需求收集 & SIG 提案

每个版本规划周期前，社区会广泛征集需求。这个环节不是公司拍板，而是 社区共建+SIG自驱：

# 示例：拉起一个新的功能分支（以 UEFI 支持为例）
git checkout -b feature-uefi-support

开发者可以在 Gitee 的各个 SIG 仓库下提交 Feature.yaml，说明要干啥、怎么干、谁来干。

第 2 步：开发 & 测试分支

开发阶段会创建特定分支（比如 openEuler-24.09），社区成员协同提交代码，自动化测试流程实时跟进。

这个阶段引入了社区特色的 obs-build、gitee-pr-bot 工具链，实现了：

• PR 自动构建测试
• 单元测试覆盖率分析
• 构建依赖自动推送

例如你提个 PR 改了 kernel 参数，CI 会自动触发如下操作：

$ obs-build trigger \
  --project openEuler:24.09 \
  --package kernel \
  --submit-pr

第 3 步：Daily 构建 + Preview 镜像产出

每天晚上，OBS（open build service）都会根据最新代码构建一次 Preview 镜像。

你可以从 openEuler 镜像仓下载 nightly build 测试：

wget https : // mirrors . openeuler . org / nightly / openEuler-24.09-x86_64.iso

构建失败？邮件通知到责任人；
包依赖缺失？CI 自动打回 PR。

第 4 步：功能冻结（Feature Freeze）

进入发布节奏的 “红线期”：

• 不再接受新的特性；
• 所有变更需社区审批 + CI 通过；
• 开始全面压力测试 + 性能测试。

这时候 SIG 会做“准发布验收”（Release Qualification Review）：

- feature: swap file 支持增强
  status: "已集成"
  test: "压力测试通过"
  verified: "YES"

第 5 步：Release Candidate 发布（RC阶段）

这就像“高考前最后一次模拟考”。

RC 版本会发给设备厂商、ISV、社区伙伴进行“非功能测试”：

• 安装体验、升级兼容性、硬件适配
• 不同CPU平台（x86、ARM、RISC-V）验证
• 容器、KVM、OpenStack等典型场景验证

每个问题都在 issue list 中记录：

[RC Bug] 安装流程卡在网络配置界面
[RC Bug] 使用 virt-manager 安装失败，疑似 display driver 兼容问题

第 6 步：正式版本 GA（General Availability）

终于，等到大版本 Release 日！

这时候产出的是一整套交付物：

• ISO 镜像（Desktop / Server）
• SDK 开发包
• 源码仓库快照（support reproducibility）
• RPM 仓库元数据
• 版本说明文档（Release Notes）
• 签名校验 + 安全白皮书

并同步发布到 [mirrors . openeuler . org]。

第 7 步：维护周期 & 后续版本管理

正式版不是终点，而是另一个开始。

openEuler 社区设有专门的“安全小组”“稳定维护 SIG”，持续修复 CVE、漏洞、内核安全补丁等。

比如你下载的是 openEuler 22.03 LTS SP3，未来每月都有补丁流持续更新。

这就像“种下一棵树，还要浇水施肥定期修枝”。

四、背后的支撑系统有多强？

发布流程能顺利跑下来，离不开一套超强社区 DevOps 工具链：

• OBS：源码包编译、镜像生成的中枢
• build-tools：自动化编译打包工具
• gitee-bot：社区 PR 流程管理神器
• cve-robot：安全漏洞扫描和修复提醒

甚至还有开源项目 openEuler-Infrastructure 专门维护这些支撑系统。

五、写在最后：别小看每一个镜像，它背后是无数人的坚持与执着

作为一个亲身参与过 openEuler SIG 的开发者，我真的体会到一件事：

“开源操作系统不是靠几个人写代码堆出来的，而是一群人日复一日，对每一行代码都较真、对每一次构建都负责。”

这份过程，是一种信念。

每当看到一个正式版本顺利发布，我都会想起那个凌晨 2 点还在 Gitee 上回 PR 评论的朋友、那个连续两周帮忙定位构建 bug 的兄弟，还有那个在 OBS 日志里翻 600 行日志找问题的自己……

openEuler 的发布流程，不只是一个流程，更是一群人的专业、协作和温度。