Version SSOT: derive everywhere from pyproject, bump to 0.5.0 - #35
Merged
Conversation
…basedpyright to tests
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Version single source of truth (SSOT) + bump to 0.5.0
One number is the source of truth and everything else derives from it, so the version can never drift across the CLI, TUI, web UI, docs, and
pip installagain.Design
pyproject.toml [project] versionis the ONE source. It is0.5.0now.claude_comms.__version__is derived from installed package metadata viaimportlib.metadata(unchanged), and--versionreads it."version": __version__fromGET /api/capabilities. The store hydratesserverVersionfrom that response, and the sidebar badge prefers the live daemon version, falling back to the build-timepackage.jsonvalue only until capabilities load. A stale bundle can no longer display a wrong number.web/package.jsonis kept in lock step withpyproject.toml(the build-time fallback) and a CI test (tests/test_version_consistency.py) fails the build on any drift between the two static sources. The runtime__version__check is lenient (importable + version-shaped) so a stale local editable install does not hard-fail CI — the static-source match is the authoritative guard.img.shields.io/pypi/v/claude-comms) and refreshed the tests badge.scripts/bump_version.py: future releases runpython scripts/bump_version.py X.Y.Zto validate semver, bump both files together, prepend a CHANGELOG stub, commitRelease vX.Y.Z, and create the annotated tag. It refuses to re-bump an existing version or clobber an existing tag, and never pushes.This release itself was hand-edited (pyproject + package.json + CHANGELOG) rather than run through the script, so the whole bump is contained in this PR. No git tag is created here.
Stale-version finding
README "Known Issues" had a stale row:
Version mismatch — Sidebar shows "v0.9" vs Python "0.1.0" — cosmetic only. That is exactly what this SSOT work eliminates, so the row is now marked Resolved with a one-line explanation of the new mechanism.Also folded in
[[tool.basedpyright.executionEnvironments]]block scoping the unused/unreachable diagnostic classes to thetests/tree only (src/keeps full reporting).Gates
ruff format+ruff checkclean;basedpyright src/claude_commsintroduces zero new targeted diagnostics vs main.pytest -qgreen: 1469 passed (includes the newtest_version_consistency.py).vitestgreen: 1193 passed;vite buildcompiles and bakes0.5.0into the bundle.After merge
0.5.0.🤖 Generated with Claude Code