diff --git "a/oEEP/oEEP-0000 oEEP  \347\264\242\345\274\225.md" "b/oEEP/oEEP-0000 oEEP  \347\264\242\345\274\225.md"
index 91b60369570273fd3e1b8fa2c8360aea2a644f64..1bafb8938d5478b3e7149846459f91b9f3d18eb8 100644
--- "a/oEEP/oEEP-0000 oEEP  \347\264\242\345\274\225.md"	
+++ "b/oEEP/oEEP-0000 oEEP  \347\264\242\345\274\225.md"	
@@ -34,6 +34,7 @@
 | 0019 | P,I | [openEuler社区部分软件包自动化管理流程](oEEP-0019%20openEuler社区部分软件包自动化管理流程.md) | 曹志 (george at openeuler.sh) | 2024-11-28 |
 | 0020 | S,A | [openEuler源码树与构建树分离策略](oEEP-0020%20openEuler源码树与构建树分离策略.md) | Funda Wang (fundawang at yeah.net) | 2024-10-23 |
 | 0021 | P,I | [openEuler软件包版本监控配置](oEEP-0021%20openEuler软件包版本监控配置.md) | 翟文杰(zwjsec at huawei.com) | 2025-03-10 |
+| 0022 | D,P | [openEuler多版本包管理规范](oEEP-0022%20openEuler多版本包管理规范.md) | 刘恺(kai.liu at windriver.com) | 2025-04-01 |
 
 ## oEEP 类型分类：
 - D (Document, 信息整理): 信息梳理形成的文档。此类 oEPP 包含社区索引，指南，规范或其他和 openEuler 相关的信息。
diff --git "a/oEEP/oEEP-0022 openEuler\345\244\232\347\211\210\346\234\254\345\214\205\347\256\241\347\220\206\350\247\204\350\214\203.md" "b/oEEP/oEEP-0022 openEuler\345\244\232\347\211\210\346\234\254\345\214\205\347\256\241\347\220\206\350\247\204\350\214\203.md"
new file mode 100644
index 0000000000000000000000000000000000000000..bc641e0d228c12d1aa34e44adf37af595a477b68
--- /dev/null
+++ "b/oEEP/oEEP-0022 openEuler\345\244\232\347\211\210\346\234\254\345\214\205\347\256\241\347\220\206\350\247\204\350\214\203.md"	
@@ -0,0 +1,129 @@
+---
+标题:    openEuler多版本包管理规范
+类别:    信息整理
+摘要:    规范openEuler多版本包的管理，包括打包方案、仓库和包本身的管理等
+作者:    刘恺（kai.liu at windriver.com）
+状态:    基本成型
+编号:    oEEP-0022
+创建日期: 2025-04-01
+修订日期: 2025-04-01
+---
+
+## 背景与动机
+
+当前openEuler已经有大量包因为各类原因提供了多个版本供选择安装，但社区尚缺乏统一的规范要求，导致这些包的做法各有差异。因此撰写此规范帮助统一。另外，有些相关技术已经发生改变，也一并在本规范中进行介绍并给出指导意见。
+
+### 业界情况
+
+由于RPM包管理器原生未对多版本提供支持，Red Hat历史上设计了两种方案来更好的支持多版本：
+
+#### Modularity
+
+通过对RPM仓的修改来提供开启/关闭不同版本的包的仓库源（即module）的能力，以此提供多个版本的包供选择安装。但无法同时安装和运行多个版本。
+
+但[Fedora已经放弃了Modularity，自39开始不再支持](https://fedoraproject.org/wiki/Changes/RetireModularity)。由于长生命周期支持，当前版本的RHEL还在继续使用。
+
+#### Software Collections (SCL)
+
+通过修改spec文件，将不同版本安装到不同的路径prefix下，并且通过`scl-utils`工具来选择运行的版本。改方案提供了同时安装和运行多个版本的能力。但该方案[从未被正式接纳进入Fedora](https://fedoraproject.org/wiki/Changes/SCL)。
+
+该方案也已经被抛弃，上游已经[宣布EOL](https://www.softwarecollections.org/en/)。官网甚至也进入无维护状态，SSL证书已经于2024年过期。
+
+自此，Fedora已经抛弃了Modularity和SCL两者，回归到朴素的包名加版本号的方式。这也是其它主流发行版如openSUSE、Debian、Ubuntu等使用的方式，包括openEuler也采用该方式。但openEuler目前也有一些包采用了SCL方式打包，这些包应逐步改造，并将`scl-utils`包衰退。
+
+## 对 openEuler 的益处
+
+openEuler目前多版本支持存在以下问题：
+
+1. 仓库和分支管理方式混乱: 既有分仓库管理多个版本的，也有一个仓库内使用Multi-Version分支管理的，也有两种方式都用的。
+
+2. 仓库和包命名略混乱：有包名和版本号之间没有分隔的（如redis5，redis6），也有采用“-”号分隔的（如 gcc-10，gcc-14，openjdk-11，openjdk-17，postgresql-13）。
+
+3. 还在使用已经不再维护的SCL技术和相关`scl-utils`工具。
+
+本文定义了多版本软件包的管理规范，解决以上问题，统一多版本包的开发和管理，避免混乱，以达到提升社区开发者的开发体验，优化用户使用体验的目的。
+
+## 方案描述
+
+### 多版本包分类
+
+- L0：无多版本需求
+
+- L1：多个版本可供安装，但只需要安装单一版本，如：
+  - 脚本语言，如python，perl，ruby，nodejs
+  - 数据库，如mysql，mariadb，postgresql，redis
+
+- L2：需要同时安装和使用多个版本，如：
+  - 工具链：gcc，clang/llvm，openjdk，rust。这些工具会出现多个版本共存的需求，以满足多个软件包的不同依赖。
+
+由于应用兼容性的需求，用户所需要的版本往往与OS提供的默认版本不匹配。此时L1级支持为用户提供额外的版本，提升用户体验，并可降低用户从其它发行版迁移到openEuler的兼容性差异。
+
+从打包角度分析，L2与L1级的打包工作差异并不大，但发布和生命周期管理更为复杂。因此建议在技术可行时按照L2级方式来打包，但是否提供L2级能力由相关SIG组自行决定。用户的L2类需求通常也可以通过容器来转化为L1类。
+
+多版本包的管理涉及到软件包的整个生命周期：
+
+1. 代码仓管理
+
+2. 打包
+
+3. 发布
+
+4. 部署和运行
+
+### 代码仓管理
+
+软件包的多个版本使用独立代码仓管理，每个版本对应一个仓库。仓库内的分支对应OS版本，即遵循当前openEuler标准的分支管理模式。
+
+代码仓和软件包命名需保持一致，统一格式为`P-V`。其中`V`为多个版本区分的版本号，通常为软件包的大版本号。在`P`和`V`之间加入`-`符号以避免包名最后一个字符为数字时出现歧义。
+
+如果需要为系统提供一个默认版本，则不带任何版本后缀，直接命名为`P`，而`P-V`则锁定具体的版本。默认版本可能是最新版本，也可能不是，由软件包维护者和相关SIG决定。但推荐默认版本追踪上游最新版本。
+
+如`V`为`3.9`，`3.10`等形式，需去掉`.`。因[未来的RPM版本可能会将`-`之外的字符作为`%name` tag的保留字符](https://rpm-software-management.github.io/rpm/manual/spec.html#preamble)。
+
+以gcc为例，代码仓和软件包命名为：
+
+- gcc：gcc代表为系统提供的默认版本
+
+- gcc-10，gcc-12：对应gcc 10，12版本
+
+- 代码仓内分支为`openEuler-24.03-LTS`，`openEuler-24.09`等，对应OS版本。
+
+### 打包
+
+RPM spec文件中需定义`Name`为`P-V`的形式。
+
+建议采用`update-alternatives`工具来管理默认版本。如有需要，可采用`environment-modules`工具来管理多个版本的共存和动态切换。
+
+由于SCL技术上游已经EOL，不要再继续使用。例如使用`%_scl_*`宏，将软件包安装到`/opt`下等等。也不要依赖于`scl-utils`，`scl-utils-build`等包。
+
+### 发布
+
+如无特殊需要，对于多版本的软件包，一个OS版本中仅选择一个版本作为主要受支持版本（即默认版本），发布到主要包源中（OS或everything）。其它版本可发布到EPOL，具体同时支持多少个版本及生命周期长度由相关SIG组与RM团队决定。
+
+openEuler LTS版本间建议采用滚动更替的方式为多版本包提供升级路径。例：
+
+| OS版本 | SP版本  | everything | EPOL     | 说明                                                                                |
+| :----- | :------ | :--------- | :------- | :---------------------------------------------------------------------------------- |
+| 24.03  | SP0     | v1         |          | 某软件包上游发布v1，引入openEuler                                                   |
+| 24.03  | SP1/2/3 | v1         | v2       | 此时上游发布v2，提供多版本包并引入EPOL                                              |
+| 26.03  | SP0     | v2         | v1       | 新OS版本，选择v2作为默认版本。并在EPOL中提供v1，便于从24.03升级的用户维持应用兼容性 |
+| 26.03  | SP1/2/3 | v2         | v3, (v1) | 此时上游发布v3，引入EPOL。视该软件包的支持策略决定v1是否继续保留                    |
+| 28.03  | SP0     | v3         | v2, (v1) | 同理，28.03发布时使用最新v3版本作为默认版本，同时EPOL中提供上一个版本便于用户升级   |
+| 28.03  | SP1/2/3 | v3         | v4       | 继续引入新版本                                                                      |
+
+### 部署和运行
+
+由于SCL技术上游已经EOL，不应再继续使用`scl`工具来部署多版本。
+
+## 范围/相关软件
+
+需要提供多版本的包包括以下几大类：
+
+1. 编译器和工具链，如：gcc，clang/llvm，jdk，rust
+1. 脚本语言引擎及模块，如：python，perl，ruby，nodejs
+3. 数据库软件，如：mysql，mariadb，postgresql，redis
+4. 其它特定大型软件，如：ROS
+
+## 升级与兼容性影响
+
+`scl-utils`工具需要衰退并将相关使用SCL技术的包逐步改造。