[Bug]: main reports vllm-omni 0.20.x.dev while codebase/docs target vLLM 0.21.0 — v0.21.0rc1 tagged off main

[hsliuustc0106]

Your code version

vllm: 0.21.0
vllm-omni (editable from main): 0.20.1.dev181+g5f9aee193
git HEAD: 5f9aee19 (origin/main as of 2026-05-25)

Summary

main has been rebased to vLLM 0.21.0 (PR #3530), and docs/CI target vllm==0.21.0. However, editable installs from main report vllm_omni version 0.20.1.dev181+... via setuptools-scm, because the v0.21.0rc1 tag is not on main's history.

This causes a false major/minor mismatch (0.20 vs 0.21) against the documented/test baseline and triggers version-alignment checks / warn_if_misaligned_vllm_version() warnings even when the code is on the 0.21.0 rebase line.

Expected behavior

After the v0.21.0 rebase landed on main, setuptools-scm on latest main should derive a 0.21.x dev version (e.g. from v0.21.0rc1-N-g... or v0.21.0), aligned with:

• docs recommending uv pip install vllm==0.21.0
• CI / most Dockerfiles using v0.21.0
• PR [Rebase] Rebase to vllm v0.21.0 #3530 [Rebase] Rebase to vllm v0.21.0

Actual behavior

On latest main:

git describe --tags --always --long HEAD
# v0.20.0-181-g5f9aee19

python -c 'from setuptools_scm import get_version; print(get_version(root="."))'
# 0.20.1.dev181+g5f9aee193

python -c 'import vllm, vllm_omni; print(vllm.__version__, vllm_omni.__version__)'
# 0.21.0 0.20.1.dev181+g5f9aee193

Major/minor alignment check fails: 0.21 vs 0.20.

Root cause (git topology)

The v0.21.0rc1 tag points to 04c4c674, which is not an ancestor of main:

Commit	Description	On main?
eb4e60ee	[Rebase] Rebase to vllm v0.21.0 (#3530)	Yes
67d672db	Release pipeline (#3428) — tag branch	No
bc26cad1	Release pipeline (#3428) — main	Yes
04c4c674	Twine upload — tag branch	No
5549b7f4	Twine upload (#3667) — main	Yes
v0.21.0rc1 → 04c4c674		No

Verification:

git merge-base --is-ancestor v0.21.0rc1 origin/main && echo yes || echo no
# no

git merge-base --is-ancestor v0.20.0 origin/main && echo yes || echo no
# yes

git log --oneline origin/main..v0.21.0rc1
# 04c4c674 Enable twine upload to PyPI in release pipeline
# 67d672db [CI/Build] Unify release pipeline with NIGHTLY=1 option, add x86_64/aarch64 image builds (#3428)

The fork point between main and v0.21.0rc1 is the rebase commit eb4e60ee. The tag sits on two CI commits that were re-merged onto main under different SHAs (bc26cad1, 5549b7f4). main then continued with ~87 more commits, while setuptools-scm still walks back to v0.20.0 (last ancestor tag on main).

setuptools-scm itself appears correct; the release tag placement is wrong.

Impact

1. False version mismatch for anyone installing editable main with vllm==0.21.0 (documented baseline).
2. warn_if_misaligned_vllm_version() fires on import (vllm_omni/version.py).
3. Validation scripts that compare major/minor block testing even though code is on the 0.21 rebase.
4. Confusing release metadata: docs list 0.21.0 pre-built wheels, but dev installs from main report 0.20.x.dev.
5. Secondary inconsistency: docker/Dockerfile.cuda still uses vllm/vllm-openai:v0.20.0 while other Dockerfiles/docs use v0.21.0.

Reproduction

git clone https://github.com/vllm-project/vllm-omni.git
cd vllm-omni
git checkout main   # e.g. 5f9aee19

git describe --tags --always --long HEAD
git merge-base --is-ancestor v0.21.0rc1 HEAD; echo "rc1 ancestor exit=$?"

uv venv --python 3.12 .venv && source .venv/bin/activate
uv pip install setuptools-scm wheel
uv pip install "vllm==0.21.0" --torch-backend=cu130
VLLM_OMNI_TARGET_DEVICE=cuda uv pip install -e . --no-build-isolation

python - <<'PY'
import re, vllm, vllm_omni
print("vllm", vllm.__version__)
print("vllm_omni", vllm_omni.__version__)
omni_mm = ".".join(re.match(r"^(\d+\.\d+)", vllm_omni.__version__).group(1).split("."))
vllm_mm = ".".join(re.match(r"^(\d+\.\d+)", vllm.__version__).group(1).split("."))
print("major.minor match:", omni_mm == vllm_mm)
PY

Proposed fix

Release/tagging fix (preferred):

• Retag or add a tag on an actual main commit after eb4e60ee, e.g.:
  • v0.21.0rc2 on current origin/main, or
  • move v0.21.0rc1 to a real main SHA such as 5549b7f4 or latest main
• Ensure future RC/stable tags are created only from commits reachable from main.

Follow-up cleanup:

• Update docker/Dockerfile.cuda base image from v0.20.0 → v0.21.0 for consistency.

Workaround (for local testing)

Use vllm==0.21.0 (matches the rebased codebase). Do not downgrade to vllm==0.20.0 just to satisfy the version string. Optionally set VLLM_OMNI_VERSION_OVERRIDE only when the mismatch is known to be tagging-related.

[hsliuustc0106]

@david6666666 @tzhouam PTAL this is quite misleading

[hsliuustc0106]

Root-cause follow-up: why v0.21.0rc1 was tagged off main

Investigated the git topology in more detail. The version mismatch was not caused by setuptools-scm or a wrong rebase — it was caused by where the RC tag was cut.

Timeline

1. May 16 — PR [Rebase] Rebase to vllm v0.21.0 #3530 rebased main to vLLM 0.21.0 at eb4e60ee.
2. May 17 ~03:42 PT — A release branch was forked directly from eb4e60ee (not from current main HEAD).
3. May 17 ~03:59 PT — v0.21.0rc1 was tagged at 04c4c674 on that release branch.
4. May 17 18:40 Beijing — The same PR ([CI/Build] Unify release pipeline with NIGHTLY=1 option, add x86_64/aarch64 image builds #3428) merged onto main separately as bc26cad1, on top of 9 other commits that the release branch never included.
5. main continued with ~87 more commits; the tag was never moved onto a reachable main SHA.

Tag branch vs main

Tag branch (where v0.21.0rc1 lives):

eb4e60ee  [Rebase] Rebase to vllm v0.21.0 (#3530)
   └─ 67d672db  [CI/Build] Unify release pipeline (#3428)   ← tag branch only
       └─ 04c4c674  Enable twine upload to PyPI             ← tag branch only
           └─ v0.21.0rc1

main (what setuptools-scm actually walks):

eb4e60ee  rebase
   ├─ 9 other merged PRs (#3613, #3655, #3502, #3214, #3602, #3470, #3659, #3338, #3009)
   └─ bc26cad1  #3428 merged on main
       └─ 5549b7f4  twine via PR #3667
           └─ … ~87 more commits …
               └─ current main

Verification:

git merge-base --is-ancestor v0.21.0rc1 origin/main  # false
git merge-base --is-ancestor v0.20.0 origin/main     # true
git describe --tags origin/main                      # v0.20.0-181-g... (before v0.21.0rc2)

Same PR titles, different commits/trees

	Tag branch	main
#3428	67d672db (parent: eb4e60ee)	bc26cad1 (parent: 9c5e35f4)
Twine upload	direct commit 04c4c674	PR #3667 5549b7f4
Tree diff vs other line	—	~40 files differ

So this was not just “different SHAs from re-merge” — the release branch was built from a stale base (post-rebase tip only), while main had already moved on.

Process gap (not a tooling bug)

1. RC branch was forked too early — directly from eb4e60ee, skipping commits on/about to land on main.
2. Tag was created from the release branch for wheel/Buildkite work, without confirming the tagged commits were ancestors of origin/main.
3. No post-tag check like git merge-base --is-ancestor <tag> origin/main.

Fix applied

• v0.21.0rc2 pushed on actual main at 5f9aee19 — setuptools-scm now reports 0.21.x on fresh main checkouts.
• Update CUDA Docker base image to vLLM v0.21.0 #3859 — updates docker/Dockerfile.cuda base image from v0.20.0 → v0.21.0.

Suggested guardrail for future releases

Before publishing an RC/stable tag:

git fetch origin --tags
git merge-base --is-ancestor "$TAG" origin/main
git describe --tags --always origin/main

The tag should be an ancestor of origin/main, and git describe origin/main should reference the new tag (not an older line like v0.20.0-N-g...).