chore(release): pin pyproject to 0.7.0rc1 + fix RELEASING.md#59
Merged
Conversation
The v0.7.0-rc1 release workflow failed at the version-match validator because pyproject.toml carried "0.7.0" but the tag normalizes to "0.7.0rc1". Bump pyproject (and the mirrored __version__ and smoke-test assertion) to the rc form so the tag can be re-pushed and the workflow can proceed to publish. Fix RELEASING.md to match what the workflow actually checks: - The pre-release checklist now says the pyproject version must match the tag after PEP 440 normalization, calls out that the rc and real-release bumps are separate commits, and lists the mirrored files that also need updating. - The "Tagging the real release" section now includes the bump-to- final-version commit step before tagging. - The "Iterating on an rc" section spells out the per-bump commit pattern and documents the recoverable tag-delete path for rcs that fail before reaching a publish step.
There was a problem hiding this comment.
Pull request overview
This PR fixes the v0.7.0-rc1 release recovery path by aligning all version pins with the v0.7.0-rc1 tag’s PEP 440-normalized form and updating the release documentation to prevent future rc/real-release mismatches.
Changes:
- Pin
project.versionand runtime/test version assertions to0.7.0rc1. - Update
uv.lock’s editable package entry to0.7.0rc1. - Rewrite
RELEASING.mdto explicitly separate rc vs real-release version bump commits and document when rc tag deletion/re-tagging is safe.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
pyproject.toml |
Bumps project version to 0.7.0rc1 to satisfy tag/version validation. |
src/openarmature/__init__.py |
Updates runtime __version__ to match the rc version. |
tests/test_smoke.py |
Updates smoke assertion to match the rc version. |
uv.lock |
Updates the editable openarmature package version to 0.7.0rc1. |
RELEASING.md |
Clarifies rc vs real-release bump/tag steps and recovery guidance. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
CoPilot caught two issues in the new RELEASING.md sections: - The "Tagging the real release" example used "chore(release): bump to v0.7.0" while the convention stated earlier in the doc is "chore(release): vX.Y.Z". Aligned the example. - The same section's shell block conflated the local commit, PR, and tag steps. Since the repo doesn't allow direct push to main, the bump always lands via PR. Restructured to match the "Tagging the rc" pattern: prose lists the files to update, then a separate code block shows only the tag-and-push commands assuming main is already updated. Applied the same shape to "Iterating on an rc" since it had the same issue.
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.
Recovery PR for the v0.7.0-rc1 release.
What happened
PR #58 set `pyproject.toml` version to `0.7.0` and I tagged `v0.7.0-rc1`. The release workflow failed at the version-match validator:
```
version mismatch: pyproject='0.7.0' vs tag='0.7.0-rc1'
(normalized: pyproject=0.7.0 tag=0.7.0rc1)
```
The check normalizes both sides to PEP 440 form and compares — `0.7.0` ≠ `0.7.0rc1`. Nothing was uploaded to TestPyPI; the workflow failed before any publish step.
The previous `RELEASING.md` text said either form was accepted in the pyproject field, which is true on its own, but missed that the rc tag and real-release tag normalize to different values, so the pyproject pin has to be bumped separately for each.
What this PR does
Next steps after merge
Test plan