docs: Release-As must ride a top-level commit message, not a squash bullet#75
docs: Release-As must ride a top-level commit message, not a squash bullet#75Alpaq92 wants to merge 1 commit into
Conversation
…ullet PR #73 carried "Release-As: 0.9.0" inside the first bulleted sub-message of its two-commit squash body and release-please ignored it, computing 0.8.16 instead. Document the pitfall and the reliable vehicle (a single-commit micro-PR whose own message carries the footer) - which is exactly what this commit is: it pins the next release. Release-As: 0.9.0 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
WalkthroughCLAUDE.md now warns that ChangesRelease Process Documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CLAUDE.md`:
- Around line 50-59: Update the Markdown paragraph in the Release-As section so
the issue reference “#64” is not the first characters of a line; prefix it with
“PR” or move it onto the preceding line while preserving the existing reference
and meaning.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| ### ⚠️ `Release-As:` is only parsed from top-level commit messages | ||
| A footer buried inside the **bulleted sub-messages of a multi-commit squash** | ||
| (GitHub's default squash body for a 2+-commit PR) is IGNORED — #73 carried | ||
| `Release-As: 0.9.0` inside its first bullet and release-please still computed | ||
| 0.8.16. Pin the version with a commit whose OWN top-level message ends with the | ||
| footer: a **single-commit** PR squash preserves the message verbatim (proven by | ||
| #64), so a docs/chore micro-PR is the reliable vehicle. Direct pushes to `main` | ||
| are blocked by the ruleset, so the empty-commit approach from release-please's | ||
| docs doesn't work here. | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Avoid starting the line with #64.
markdownlint reports MD018 on Line 56 because the issue reference begins the line with #. Prefix it with PR (or keep it on the preceding line) so the documentation passes lint without losing the issue reference.
Proposed fix
-footer: a **single-commit** PR squash preserves the message verbatim (proven by
-#64), so a docs/chore micro-PR is the reliable vehicle.
+footer: a **single-commit** PR squash preserves the message verbatim (proven by
+PR `#64`), so a docs/chore micro-PR is the reliable vehicle.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### ⚠️ `Release-As:` is only parsed from top-level commit messages | |
| A footer buried inside the **bulleted sub-messages of a multi-commit squash** | |
| (GitHub's default squash body for a 2+-commit PR) is IGNORED — #73 carried | |
| `Release-As: 0.9.0` inside its first bullet and release-please still computed | |
| 0.8.16. Pin the version with a commit whose OWN top-level message ends with the | |
| footer: a **single-commit** PR squash preserves the message verbatim (proven by | |
| #64), so a docs/chore micro-PR is the reliable vehicle. Direct pushes to `main` | |
| are blocked by the ruleset, so the empty-commit approach from release-please's | |
| docs doesn't work here. | |
| ### ⚠️ `Release-As:` is only parsed from top-level commit messages | |
| A footer buried inside the **bulleted sub-messages of a multi-commit squash** | |
| (GitHub's default squash body for a 2+-commit PR) is IGNORED — PR `#73` carried | |
| `Release-As: 0.9.0` inside its first bullet and release-please still computed | |
| 0.8.16. Pin the version with a commit whose OWN top-level message ends with the | |
| footer: a **single-commit** PR squash preserves the message verbatim (proven by | |
| PR `#64`), so a docs/chore micro-PR is the reliable vehicle. Direct pushes to `main` | |
| are blocked by the ruleset, so the empty-commit approach from release-please's | |
| docs doesn't work here. |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 56-56: No space after hash on atx style heading
(MD018, no-missing-space-atx)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CLAUDE.md` around lines 50 - 59, Update the Markdown paragraph in the
Release-As section so the issue reference “#64” is not the first characters of a
line; prefix it with “PR” or move it onto the preceding line while preserving
the existing reference and meaning.
Source: Linters/SAST tools
|
Superseded by #76, which carries the same change with CodeRabbit's MD018 fix applied. Amending this PR would have required a force-push, and adding a second commit would have buried the Release-As footer in a squash bullet — the very pitfall being documented. |
Pull request was closed
…ullet (#76) PR #73 carried "Release-As: 0.9.0" inside the first bulleted sub-message of its two-commit squash body and release-please ignored it, computing 0.8.16 instead. Document the pitfall and the reliable vehicle (a single-commit micro-PR whose own message carries the footer) - which is exactly what this commit is: it pins the next release. Supersedes #75 (CodeRabbit's MD018 fix folded in; amending that PR would have required a force-push, and adding a second commit would have buried this footer in a squash bullet - the very bug documented). Release-As: 0.9.0 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Documents the release-versioning pitfall just hit live: #73's two-commit squash buried its
Release-As: 0.9.0footer inside a bulleted sub-message, release-please ignored it, and #74 was computed as 0.8.16.This PR is also the fix: its single commit carries
Release-As: 0.9.0at top level, so once it merges, release-please recomputes #74 as the intended 0.9.0 (containing the two #73 fixes + this doc note).Docs-only — auto-approve + trusted-author auto-merge should carry it in without manual action.
🤖 Generated with Claude Code
Summary by CodeRabbit