Derive the version from the git tag - #12
Merged
Merged
Conversation
`pyproject.toml` held a hard-coded `version`, so every release needed a bump commit that had to match the tag. `hatch-vcs` now reads the version from the git tag at build time, and the tag/pyproject mismatch class of error goes away. - Declare `dynamic = ["version"]` and add the `hatch-vcs` build backend plugin. - Write the resolved version to `src/posit_cli/_version.py` (gitignored) so a wheel built from an sdist, which has no git metadata, still gets a version. - Keep a tag check in the release workflow, but compare the tag against the built version. This catches a build that missed the tag: a shallow clone, a dirty tree, or two tags on one commit. - Fetch tags in CI's build job so its artifact carries a real version. - Point `just version` at `hatch version`; `uv version` cannot read a dynamic version. Also create a GitHub release after a successful publish, and update the install docs now that posit-cli is on PyPI.
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.
Summary
versioninpyproject.tomlwithdynamic = ["version"]plus thehatch-vcsbuild plugin, so the git tag is the only source of the version. No bump commit, and no tag-vs-manifest mismatch to get wrong.src/posit_cli/_version.py(gitignored) through thehatch-vcsbuild hook, so a wheel built from an sdist — which carries no git metadata — still gets a version.release.yaml, but compares the tag against the built version. It now catches a build that missed the tag: a shallow clone, a dirty tree, or two tags on one commit.github-releasejob that runs afterpublish, so a failed PyPI upload leaves no release. It attaches the wheel and sdist, and generates notes from the commits.buildjob (fetch-depth: 0), so its artifact carries a real version instead of a0.1.dev1+g…fallback.just versionathatch version.uv versioncannot read a dynamic version.uv tool install posit-cliin the README and the Claude Code skill, now thatposit-cli0.1.0 is on PyPI. Both keep the GitHub form for unreleased changes.RELEASE.mdfor the tag-only flow, and tells agents inCLAUDE.mdnot to re-add aversionfield.uv.lockno longer records a version for the project;uv lockwrites(dynamic)instead.Releasing after this change:
Test plan
just lintpassesjust testpasses (64 tests)just test 3.8passes — the oldest supported interpreter still installs the project under the new build backenduv lock --lockedpasses, so the lockfile is stable with a dynamic versionuv buildbuilds the wheel from the sdist, which proves the sdist path resolves a version with no git present0.1.dev1+g<sha>rather than failing, so CI's shallow checkouts stay greenposit --versionfrom the built wheel reports the hatch-vcs versionvX.Y.Zonmain) to confirm the publish and the GitHub release run end-to-endThe
releaseenvironment reviewers and the PyPI trusted publisher are unchanged.RELEASE.mdstill lists both as one-time setup.