版本策略¶

从 vLLM 0.7.x 开始，vLLM Ascend 插件（vllm-project/vllm-ascend）项目遵循 PEP 440 发布与 vLLM（vllm-project/vllm）匹配的版本。

vLLM Ascend 插件版本¶

每个 vLLM Ascend 发布版本都按 v[major].[minor].[micro][rcN][.postN] 进行版本编号（例如 v0.7.3rc1、v0.7.3、v0.7.3.post1）

• 最终版本：通常每三个月安排一次，并严格对齐 vLLM 上游发布周期以及 Ascend 软件产品路线图。
• 预发布版本：通常按需发布，使用 rcN 标记表示第 N 个候选版本。它们旨在支持用户在最终版本发布前进行早期测试。
• 后续版本：通常按需发布，用于修复最终版本中的小错误。与 PEP-440 后续版本说明 的约定不同，这些版本包含实际的错误修复，因为最终版本必须严格对齐 vLLM 最终版本格式（v[major].[minor].[micro]）。任何后续版本都必须作为最终版本的补丁版本发布。

例如：

• v0.7.x：首个匹配 vLLM v0.7.x 版本的最终版本。
• v0.7.3rc1：vLLM Ascend 的首个预发布版本。
• v0.7.3.post1：如果 v0.7.3 版本存在一些小错误，则为其发布的后续版本。

发布兼容性矩阵¶

下表是 vLLM Ascend 发布版本的发布兼容性矩阵。

对于 vLLM Ascend 的 main 分支，我们通常使其兼容最新的 vLLM 发布版本以及更新的 vLLM 提交哈希。请注意，此表通常会更新，请定期查看。

发布行和 main 行是不同的安装目标。对于发布安装，请使用同一发布行中的 vLLM 和 vLLM Ascend 版本。对于 main 分支开发，请从 .github/vllm-main-verified.commit 检出确切的 vLLM 提交。不要假设任意 vLLM 标签或 PyPI 发布版本与该已验证提交具有相同的传递依赖关系。

该矩阵描述了完整的 NPU 运行时栈。仅成功的仅 CPU 可编辑构建只能验证包的构建；它不能证明所生成的环境与解析器兼容，也不能证明 NPU 运行时测试能通过。使用 --no-build-isolation 可能会绕过构建环境的依赖解析，因此在使用此类环境进行运行时测试之前，请运行 python -m pip check。

发布节奏¶

发布窗口¶

分支策略¶

vLLM Ascend 包含两个分支：main 和 dev。

• main：对应 vLLM 的 main 分支以及最新的 1 个或 2 个发布版本。它通过 Ascend CI 持续进行质量监控。
• releases/vX.Y.Z：开发分支，随 vLLM 的部分新版本创建。例如，releases/v0.13.0 是 vLLM v0.13.0 版本的开发分支。

提交通常应先合并到 main 分支，然后再 backport 到 dev 分支，以尽可能降低维护成本。

维护分支与 EOL¶

下表列出了各分支的状态。

分支状态¶

请注意，vLLM Ascend 仅针对特定的 vLLM 发布版本发布，而非每个版本都会发布。因此，您可能会注意到某些版本有对应的开发分支（例如 releases/v0.13.0），而其他版本则没有（例如 releases/v0.12.0）。vLLM Ascend 发布分支现在遵循 releases/vX.Y.Z 命名约定，取代了之前的 vX.Y.Z-dev 格式，以便与 vLLM 的分支命名标准保持一致。

通常，vLLM 的每个次要版本（例如 0.7）都对应一个 vLLM Ascend 版本分支，并支持其最新版本（例如 0.7.3），如下所示：

功能分支¶

• 分支：功能分支应以 rfc/ 前缀创建，后跟功能名称，例如 rfc/feature-name。
• 状态：功能分支在合并到主分支或被删除之前，状态为 Maintained（维护中）。
• RFC 链接：功能分支应通过相应的 RFC issue 创建。创建功能分支需要 RFC，且需获得至少两位维护者的批准。
• 计划合并时间：功能分支的最终目标是合并到主分支。如果超过三个月仍未合并，导师维护者应评估是否删除该分支。
• 导师：导师应为负责该功能分支的 vLLM Ascend 维护者。

向后兼容性¶

对于主分支，vLLM Ascend 应与 vLLM 主分支及最近的 1 到 2 个发布版本兼容。为确保向后兼容性，请按以下步骤操作：

• 主分支和目标 vLLM 发布版本（例如 vLLM 主分支和 vLLM 0.8.4）均由 Ascend E2E CI 进行测试。
• 为确保代码更改与最近的 1 到 2 个 vLLM 发布版本兼容，vLLM Ascend 在代码中引入了版本检查机制。该机制首先检查已安装的 vLLM 包版本，以决定使用哪种代码逻辑。如果用户遇到 InvalidVersion 错误，这可能表明他们安装了 vLLM 包的开发版或可编辑版本。在这种情况下，我们提供环境变量 VLLM_VERSION，让用户指定要使用的 vLLM 包版本。
• 文档更改应与最近的 1 到 2 个 vLLM 发布版本兼容。如有任何破坏性更改，应添加相应说明。

文档分支策略¶

为降低维护成本，所有分支的文档内容应保持一致，版本差异可通过 mkdocs.yml 中 extra: 块内的变量来控制。虽然这不是一项简单的任务，但这是我们应当努力遵循的原则。

备注：

• latest 文档：始终指向主分支最新的 rc 发布版本。
• rc version 文档：发布后不再进行更新。
• version 文档：持续更新 releases/vX.Y.Z 分支文档以修复文档缺陷。

软件依赖管理¶

• torch-npu：TorchNPU 每 3 个月向 PyPI 发布一个稳定版本， 每月发布一个开发版本（即 POC 版本），每天发布一个 nightly 版本。 PyPI 稳定版本可以用于 vLLM Ascend 正式版本；月度开发版本仅可用于 vLLM Ascend RC 版本以进行快速迭代；nightly 版本不能用于任何 vLLM Ascend 版本或分支。