docs: split Release checklist into pre-release/release phases - #6
docs: split Release checklist into pre-release/release phases#6pramodbn27 wants to merge 2 commits into
Conversation
…main) phases Bumping pyproject.toml/__init__.py/CHANGELOG.md happens on the feature branch, before merge. Tagging and creating the GitHub Release happen on main, after merge -- the previous single flat checklist didn't make that boundary explicit, and also never mentioned creating the GitHub Release at all (only the tag), even though the Releases tab needs a Release object, not just a tag, and release-pypi.yml already listens for both triggers. Also notes --cleanup=verbatim, without which git's default cleanup strips the CHANGELOG's ### headers from the tag message. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ient release-pypi.yml already triggers on the tag push alone -- gh release create was an extra, non-git-only step. Note the tradeoff explicitly: skipping it means the Releases tab stays empty unless someone creates one by hand later, which is accepted here rather than automated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3cbd3d4f18
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| before the first release. Doing both steps 3 and 4 means the workflow runs | ||
| twice; that's expected, not a bug — PyPI accepts the second, identical | ||
| upload as a no-op. |
There was a problem hiding this comment.
The documented sequence fires both triggers in .github/workflows/release-pypi.yml:3-8: pushing the tag starts one publish, and gh release create starts another. Since the publish action at line 46 is not configured to skip existing files, the second run attempts to upload the same versioned wheel and sdist names; PyPI rejects reused filenames rather than treating them as a no-op, so the release workflow ends in failure. Remove one trigger or explicitly make the publishing job idempotent instead of instructing maintainers to expect two successful uploads.
Useful? React with 👍 / 👎.
1 participant
AGENTS.md's Release checklist was a single flat list that didn't distinguish what happens on the branch (version bump) from what happens on
mainafter merge (tag + push). It also implied a GitHub Release object gets created somewhere, which it never actually described how to do.Splits it into two phases:
pyproject.toml/__init__.py/CHANGELOG.md, commit as part of the PR.git tag(with--cleanup=verbatim-- git's default cleanup silently strips#-prefixed lines, which eats the CHANGELOG's###headers from the tag message) +git push. NoghCLI.Explicitly notes the tradeoff: skipping a GitHub Release object means the Releases tab stays empty unless someone creates one by hand later -- accepted here, not an oversight.
🤖 Generated with Claude Code