版本控制策略

版本控制策略#

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

每个vllm-ascend版本将采用以下版本号格式：v[major].[minor].[micro][rcN][.postN]（例如 v0.7.3rc1, v0.7.3, v0.7.3.post1)

正式版本发布: 通常每3个月发布一次，将综合考虑vLLM上游发布计划和昇腾软件产品发布计划。
预发布版本: 通常将按需发布, 以rcN结尾, 表示第N个候选发布版本, 用于支持用户在最终版本发布前进行早期测试。
后续发布版本: 通常将按需发布以解决最终版本中的小错误。这与PEP-440后续发布说明建议不同，考虑到最终发布版本必须严格匹配vLLM最终发布版本(v[major].[minor].[micro])，它将包含实际的错误修复。后续版本必须作为最终发布的补丁版本发布。

例如：

vllm-ascend 有主分支和开发分支。

通常情况下，一个提交应该首先仅合并到主分支，然后再反向移植到开发分支，以尽可能降低维护成本。

分支状态将处于以下其中一种状态：

请注意，vllm-ascend仅会针对特定的vLLM发布版本进行发布，而非所有版本。因此，您可能只会看到部分版本有开发分支（例如只有0.7.1-dev / 0.7.3-dev而没有0.7.2-dev），这是预期行为。

通常，vLLM的每个次要版本（如0.7）都会对应一个vllm-ascend版本分支，并支持其最新版本（例如我们计划支持0.7.3版本），如下所示：

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

如上所示：

latest 文档：匹配当前维护分支 vX.Y.Z-dev（在首个正式版本发布后将变为 main）。持续更新以确保最新版本的可用性。
version 文档：对应特定发布版本（例如 v0.7.3、v0.7.3rc1）。发布后不再更新。
stable 文档 (尚未发布): 官方正式版文档。发布后允许实时更新，通常基于vX.Y.Z-dev版本。当稳定版文档可用时，非稳定版本应显示标题警告: You are viewing the latest developer preview docs. Click here to view docs for the latest stable release..

以下是vLLM Ascend插件的版本兼容性矩阵：

vllm-ascend	vLLM	Python	稳定版CANN	PyTorch/torch_npu	MindIE Turbo
v0.7.3.post1	v0.7.3	3.9 - 3.11	8.1.0	2.5.1 / 2.5.1	2.0rc1
v0.7.3	v0.7.3	3.9 - 3.11	8.1.0	2.5.1 / 2.5.1	2.0rc1
v0.7.3rc2	v0.7.3	3.9 - 3.11	8.0.0	2.5.1 / 2.5.1.dev20250320	/
v0.7.3rc1	v0.7.3	3.9 - 3.11	8.0.0	2.5.1 / 2.5.1.dev20250308	/
v0.7.1rc1	v0.7.1	3.9 - 3.11	8.0.0	2.5.1 / 2.5.1.dev20250218	/