docs: update RELEASING.md for strict PR-based release flow#49
docs: update RELEASING.md for strict PR-based release flow#49JohnRDOrazio merged 1 commit intodevfrom
Conversation
Both main and dev are now protected with enforce_admins. The release process uses a release/* branch with a PR to main, and a separate PR to dev for the next-dev-version bump.
📝 WalkthroughWalkthroughRelease process documentation was restructured to introduce PR-based gates and intermediate release branches. The workflow now uses dedicated release branches and PRs instead of direct commits to dev/main, with steps reorganized accordingly and the quick reference diagram updated. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
RELEASING.md (1)
107-114: Consider making the branch context explicit.The
gh pr createcommand relies on the current branch beingrelease/0.2.0from Step 1. Consider either adding a note that the user should still be on that branch, or making it explicit in the command with--head release/0.2.0.📝 Suggested clarification
Option 1 - Add explicit head reference:
-gh pr create --base main --title "Release 0.2.0" \ +gh pr create --base main --head release/0.2.0 --title "Release 0.2.0" \ --body "Merge release 0.2.0 into main for tagging."Option 2 - Add a note:
### 2. Open a PR to `main` From the `release/0.2.0` branch, create a pull request:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@RELEASING.md` around lines 107 - 114, Clarify the branch context for the GH PR step by either adding the explicit head flag to the gh pr create command (e.g., include --head release/0.2.0) or by adding a one-line note above the step stating the user should be on the release/0.2.0 branch before running gh pr create --base main --title "...", so the intent of the gh pr create and the release/0.2.0 branch is unambiguous.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@RELEASING.md`:
- Around line 158-167: The fenced ASCII-art code block shown (the
triple-backtick block containing the release diagram starting with "dev
dev") lacks a language identifier; update the opening fence from ``` to ```text
so the block becomes a labeled text block (e.g., change the opening fence of the
ASCII diagram to ```text) to satisfy MD040/fenced-code-language linting.
---
Nitpick comments:
In `@RELEASING.md`:
- Around line 107-114: Clarify the branch context for the GH PR step by either
adding the explicit head flag to the gh pr create command (e.g., include --head
release/0.2.0) or by adding a one-line note above the step stating the user
should be on the release/0.2.0 branch before running gh pr create --base main
--title "...", so the intent of the gh pr create and the release/0.2.0 branch is
unambiguous.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| ``` | ||
| dev dev | ||
| │ │ | ||
| │ prepare-release.py tag & push │ | ||
| │ (strips -dev) (on main) │ | ||
| │ │ │ ┌─ PyPI │ set-version.py 0.4.0 | ||
| ▼ ▼ ▼ │ │ │ | ||
| 0.3.0-dev ──▸ 0.3.0 ──merge──▸ main ──tag──▸ CI ────┼─ GitHub Release│ ▼ | ||
| └─ GHCR └── 0.4.0-dev | ||
| dev dev | ||
| │ │ | ||
| │ release/0.2.0 branch PR → main tag │ | ||
| │ prepare-release.py (CI gate) (push) │ | ||
| │ │ │ │ ┌─ PyPI │ chore/next-dev-version | ||
| ▼ ▼ ▼ ▼ │ │ set-version.py 0.3.0 | ||
| 0.2.0-dev ──▸ 0.2.0 ──PR──▸ main (merge) ──tag──▸ CI ──────┼─ GitHub │ PR → dev | ||
| └─ GHCR └── 0.3.0-dev | ||
| ``` |
There was a problem hiding this comment.
Add language identifier to fenced code block.
The fenced code block should specify a language identifier to satisfy markdown linting rules. For ASCII art diagrams, use text.
🔧 Proposed fix
-```
+```text
dev dev
│ │As per coding guidelines, static analysis flagged: "Fenced code blocks should have a language specified (MD040, fenced-code-language)".
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 158-158: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RELEASING.md` around lines 158 - 167, The fenced ASCII-art code block shown
(the triple-backtick block containing the release diagram starting with "dev
dev") lacks a language identifier; update the opening fence from ``` to ```text
so the block becomes a labeled text block (e.g., change the opening fence of the
ASCII diagram to ```text) to satisfy MD040/fenced-code-language linting.
1 participant
Summary
dev/mainbranch model with strict branch protectionrelease/*branches with PRs tomain(no direct push)devTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit