fix(version): derive version from metadata; re-lock on release (fixes red main)#30
Merged
Conversation
… red main)
Two related fixes.
1. Version display drift. `ultan --version` / `ultan doctor` printed a HARDCODED
`__version__ = "0.2.0"` in ultan/__init__.py that set-version.sh never touched,
so after the 0.3.0 release doctor reported 0.2.0 while the installed dist was
0.3.0. Root cause: a second source of version truth. Fix: derive `__version__`
from importlib.metadata (single source = pyproject -> wheel), computed lazily
via PEP 562 so the `ultan hook` hot path never pays the lookup (verified by
test_hook_import).
2. Stale lockfile reddened main. set-version.sh bumped every workspace member in
pyproject but never re-locked, so uv.lock kept 0.2.0 and `uv sync --locked`
(CI) failed on main after the v0.3.0 release merged — and the self-stamped
ci-success on the release PR meant it was never caught pre-merge. Fixes:
- set-version.sh now runs `uv lock` after the version edits.
- release.yml sets up uv and runs `uv sync --locked` before stamping
ci-success, so the stamp reflects the only checks that can change for a
version bump (coherence + lockfile), not a blind bypass.
- uv.lock regenerated to 0.3.0 here, which un-reds main on merge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Two related fixes
1.
ultan --version/doctorreported the wrong versionultan/__init__.pyhardcoded__version__ = "0.2.0", whichset-version.shnever touched — so after the v0.3.0 release, doctor said0.2.0while the installed dist was0.3.0. Root cause: a second source of version truth. Fix: derive__version__fromimportlib.metadata(single source = pyproject → wheel), lazily (PEP 562) so theultan hookhot path never pays the lookup (guarded bytest_hook_import).2. The v0.3.0 release left
main's CI redset-version.shbumped every workspace member in pyproject but never re-locked, souv.lockkept0.2.0anduv sync --lockedfailed on main — and the self-stampedci-successon the release PR meant it was never caught. Fixes:set-version.shnow runsuv lockafter the edits.release.ymlsets up uv and runsuv sync --lockedbefore stampingci-success, so the stamp reflects the only checks that can change for a version bump (coherence + lockfile), not a blind bypass.uv.lockregenerated to0.3.0here — un-reds main on merge.Note: the
uv.lockdiff is 5 version-string lines only (the workspace members0.2.0 → 0.3.0); zero dependency changes.🤖 Generated with Claude Code