Describe the bug
has_changes() in scripts/release.py only considers .py and .ts files when deciding which packages to version-bump at release time:
relevant_files = [f for f in changed_files if f.suffix in [".py", ".ts"]]
return len(relevant_files) >= 1
If a sub-package only has lockfile changes between tags (e.g. uv.lock from dependabot), the function returns False and the package's pyproject.toml version is never bumped to the CalVer tag. It keeps whatever stale version is on main.
To Reproduce
Between tags 2026.1.14 and 2026.1.26, the only change in src/git/ was uv.lock:
git diff --name-only 2026.1.14 2026.1.26 -- src/git/
# src/git/uv.lock
The release script skipped src/git/, so pyproject.toml stayed at 0.6.2:
git show 2026.1.26:src/git/pyproject.toml | grep '^version'
# version = "0.6.2"
git show 2026.1.14:src/git/pyproject.toml | grep '^version'
# version = "2026.1.14"
Expected behavior
src/git/pyproject.toml should read version = "2026.1.26" on the 2026.1.26 tag, since the package directory had changes included in that release.
Logs
N/A this is in the release automation, not a runtime issue.
Additional context
Downstream consumers (SBOM generators, CVE scanners) key off the version in pyproject.toml. When it says 0.6.2, advisories with CalVer "fixed in" thresholds never match, so scanners flag the package as vulnerable even though the source is identical to a patched release.
Describe the bug
has_changes()inscripts/release.pyonly considers.pyand.tsfiles when deciding which packages to version-bump at release time:If a sub-package only has lockfile changes between tags (e.g.
uv.lockfrom dependabot), the function returnsFalseand the package'spyproject.tomlversion is never bumped to the CalVer tag. It keeps whatever stale version is onmain.To Reproduce
Between tags
2026.1.14and2026.1.26, the only change insrc/git/wasuv.lock:git diff --name-only 2026.1.14 2026.1.26 -- src/git/ # src/git/uv.lockThe release script skipped
src/git/, sopyproject.tomlstayed at0.6.2:Expected behavior
src/git/pyproject.tomlshould readversion = "2026.1.26"on the2026.1.26tag, since the package directory had changes included in that release.Logs
N/A this is in the release automation, not a runtime issue.
Additional context
Downstream consumers (SBOM generators, CVE scanners) key off the version in
pyproject.toml. When it says0.6.2, advisories with CalVer "fixed in" thresholds never match, so scanners flag the package as vulnerable even though the source is identical to a patched release.