Versioning Policy#
从 vLLM 0.7.x 开始，vLLM Ascend 插件（vllm-project/vllm-ascend）项目遵循 PEP 440 ，以与 vLLM（vllm-project/vllm）版本匹配发布。
vLLM Ascend 插件版本#
Each vLLM Ascend release is versioned as v[major].[minor].[micro][rcN][.postN] (such as
v0.7.3rc1, v0.7.3, v0.7.3.post1)
Final releases: Typically scheduled every three months, with careful alignment to the vLLM upstream release cycle and the Ascend software product roadmap.
Pre releases: Typically issued on demand, labeled with rcN to indicate the Nth release candidate. They are intended to support early testing by users ahead of the final release.
Post releases: Typically issued on demand to address minor errors in a final release. Different from PEP-440 post release note convention, these versions include actual bug fixes, as the final release version must strictly align with the vLLM final release format (
v[major].[minor].[micro]). Any post version must be published as a patch version of the final release.
例如：
v0.7.x: first final release to match the vLLMv0.7.xversion.v0.7.3rc1: first pre version of vLLM Ascend.v0.7.3.post1: post release for thev0.7.3release if it has some minor errors.
Release compatibility matrix#
The table below is the release compatibility matrix for vLLM Ascend release.
vLLM Ascend |
vLLM |
Python |
Stable CANN |
PyTorch/torch_npu |
MindIE Turbo |
|---|---|---|---|---|---|
v0.12.0rc1 |
v0.12.0 |
>= 3.10, < 3.12 |
8.3.RC2 |
2.8.0 / 2.8.0 |
|
v0.11.0rc3 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC2 |
2.7.1 / 2.7.1.post1 |
|
v0.11.0rc2 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC2 |
2.7.1 / 2.7.1 |
|
v0.11.0rc1 |
v0.11.0 |
>= 3.9, < 3.12 |
8.3.RC1 |
2.7.1 / 2.7.1 |
|
v0.11.0rc0 |
v0.11.0rc3 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.2rc1 |
v0.10.2 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.1rc1 |
v0.10.1/v0.10.1.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.10.0rc1 |
v0.10.0 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.7.1 / 2.7.1.dev20250724 |
|
v0.9.2rc1 |
v0.9.2 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1.post1.dev20250619 |
|
v0.9.1 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc3 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc2 |
v0.9.1 |
>= 3.9, < 3.12 |
8.2.RC1 |
2.5.1 / 2.5.1.post1 |
|
v0.9.1rc1 |
v0.9.1 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1.post1.dev20250528 |
|
v0.9.0rc2 |
v0.9.0 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.9.0rc1 |
v0.9.0 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.8.5rc1 |
v0.8.5.post1 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
|
v0.8.4rc2 |
v0.8.4 |
>= 3.9, < 3.12 |
8.0.0 |
2.5.1 / 2.5.1 |
|
v0.7.3.post1 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
2.0候选版本1 |
v0.7.3 |
v0.7.3 |
>= 3.9, < 3.12 |
8.1.RC1 |
2.5.1 / 2.5.1 |
2.0候选版本1 |
发布节奏#
Release window#
日期 |
事件 |
|---|---|
2025.12.13 |
Release candidates, v0.12.0rc1 |
2025.12.03 |
Release candidates, v0.11.0rc3 |
2025.11.21 |
Release candidates, v0.11.0rc2 |
2025.11.10 |
Release candidates, v0.11.0rc1 |
2025.09.30 |
Release candidates, v0.11.0rc0 |
2025.09.16 |
Release candidates, v0.10.2rc1 |
2025.09.04 |
Release candidates, v0.10.1rc1 |
2025.09.03 |
v0.9.1 Final release |
2025.08.22 |
Release candidates, v0.9.1rc3 |
2025.08.07 |
Release candidates, v0.10.0rc1 |
2025.08.04 |
Release candidates, v0.9.1rc2 |
2025.07.11 |
候选发布版本，v0.9.2rc1 |
2025.06.22 |
候选发布版本，v0.9.1rc1 |
2025.06.10 |
候选发布版本，v0.9.0rc2 |
2025.06.09 |
候选发布版本本，v0.9.0rc1 |
2025.05.29 |
v0.7.x 补丁版，v0.7.3.post1 |
2025.05.08 |
v0.7.x 正式版，v0.7.3 |
2025.05.06 |
候选发布版本，v0.8.5rc1 |
2025.04.28 |
候选发布版本，v0.8.4rc2 |
2025.04.18 |
候选发布版本，v0.8.4rc1 |
2025.03.28 |
候选发布版本，v0.7.3rc2 |
2025.03.14 |
候选发布版本，v0.7.3rc1 |
2025.02.19 |
候选发布版本，v0.7.1rc1 |
分支策略#
vLLM Ascend includes two branches: main and dev.
main: corresponds to the vLLM main branch and latest 1 or 2 release version. It is continuously monitored for quality through Ascend CI.
vX.Y.Z-dev：开发分支，是随着 vLLM 新版本的一部分一起创建的。例如，
v0.7.3-dev是 vLLMv0.7.3版本的开发分支。
Commits should typically be merged into the main branch first, and only then backported to the dev branch, to reduce maintenance costs as much as possible.
Maintenance branch and EOL#
The table below lists branch states.
分支 |
Time Frame |
摘要 |
|---|---|---|
维护中 |
大约 2-3 个小版本 |
Bugfixes received; releases produced; CI commitment |
无人维护 |
Community-interest driven |
Bugfixes received; no releases produced; no CI commitment |
生命周期结束（EOL） |
不适用 |
该分支不再接受更改 |
Branch states#
Note that vLLM Ascend will only be released for a certain vLLM release version, not for every version. Hence, you may notice that some versions have corresponding dev branches (e.g. 0.7.1-dev and 0.7.3-dev ), while others do not (e.g. 0.7.2-dev).
Usually, each minor version of vLLM (such as 0.7) corresponds to a vLLM Ascend version branch and supports its latest version (such as 0.7.3), as shown below:
分支 |
State |
注释 |
|---|---|---|
main |
维护中 |
CI commitment for vLLM main branch |
v0.11.0-dev |
维护中 |
CI commitment for vLLM 0.11.0 version |
v0.9.1-dev |
维护中 |
vLLM 0.9.1 版本的 CI 承诺 |
v0.7.3-dev |
维护中 |
vLLM 0.7.3 版本的 CI 承诺 |
v0.7.1-dev |
无人维护 |
已被 v0.7.3-dev 替代 |
Feature branches#
分支 |
State |
RFC Link |
Scheduled Merge Time |
Mentor |
|---|---|---|---|---|
rfc/long_seq_optimization |
维护中 |
https://github.com/vllm-project/vllm/issues/22693 |
930 |
wangxiyuan |
Branch: The feature branch should be created with a prefix
rfc/followed by the feature name, such asrfc/feature-name.State: The state of the feature branch is
Maintaineduntil it is merged into the main branch or deleted.RFC Link: The feature branch should be created with a corresponding RFC issue. The creation of a feature branch requires an RFC and approval from at least two maintainers.
Scheduled Merge Time: The final goal of a feature branch is to be merged into the main branch. If it remains unmerged for more than three months, the mentor maintainer should evaluate whether to delete the branch.
Mentor: The mentor should be a vLLM Ascend maintainer who is responsible for the feature branch.
向后兼容性#
For main branch, vLLM Ascend should works with vLLM main branch and latest 1 or 2 releases. To ensure backward compatibility, do as follows:
Both main branch and target vLLM release, such as the vLLM main branch and vLLM 0.8.4, are tested by Ascend E2E CI.
To make sure that code changes are compatible with the latest 1 or 2 vLLM releases, vLLM Ascend introduces a version check mechanism inside the code. It checks the version of the installed vLLM package first to decide which code logic to use. If users hit the
InvalidVersionerror, it may indicate that they have installed a dev or editable version of vLLM package. In this case, we provide the env variableVLLM_VERSIONto let users specify the version of vLLM package to use.Document changes should be compatible with the latest 1 or 2 vLLM releases. Notes should be added if there are any breaking changes.
Document branch policy#
为了减少维护成本，所有分支的文档内容应保持一致，版本差异可以通过 docs/source/conf.py 中的变量进行控制。虽然这并非易事，但这是我们应当努力遵循的原则。
版本 |
用途 |
代码分支 |
|---|---|---|
最新 |
最新开发分支的文档 |
vX.Y.Z-dev（在第一个正式版本发布后将成为 |
版本 |
历史版本文档 |
Git 标签，如 vX.Y.Z[rcN] |
stable (not yet released) |
最新正式发布分支的文档 |
首个正式发布后将会是 |
Notes:
latestdocumentation: Matches the current maintenance branchvX.Y.Z-dev(will bemainafter the first final release). It is continuously updated to ensure usability for the latest release.versiondocumentation: Corresponds to specific released versions (e.g.,v0.7.3,v0.7.3rc1). There are no further updates after release.stable文档（尚未发布）：官方发布版文档。发布后允许实时更新，通常基于 vX.Y.Z-dev。一旦稳定版文档可用，非稳定版本应显示一个顶部警告：您正在查看最新的开发预览文档。点击此处查看最新稳定版本文档。
Software dependency management#
torch-npu: Ascend Extension for PyTorch (torch-npu) releases a stable version to PyPi every 3 months, a development version (aka the POC version) every month, and a nightly version every day. The PyPi stable version CAN be used in vLLM Ascend final version, the monthly dev version ONLY CAN be used in vLLM Ascend RC version for rapid iteration, and the nightly version CANNOT be used in vLLM Ascend any version and branch.