Retire the in-repo changelog in favor of PR-sourced release notes - #864
Conversation
The unreleased section of docs/changelog.qmd had grown to 56 entries, many of them paragraph-length, and every PR had to edit the same file, so it conflicted constantly and duplicated what the releases page already tracks. Reduce the page to a stub pointing at the releases page, so the published changelog.html URL keeps resolving, and point the sidebar entry at GitHub Releases directly. User-facing information now lives in the pull request that makes the change: the PR template gains "User-facing changes" and "Breaking changes" sections, and the draft-release skill assembles the release notes from them at tag time. While making the skill load-bearing, fix three things that would have cost the next release: it scoped PRs to origin/master although work lands on dev, it compressed each PR to a single entry in a single section, and it let internal-only PRs fall through to Bug Fixes. It also now points the drafter at the pre-stub changelog blob, which holds curated text for work already merged.
|
Warning Review limit reached
Next review available in: 29 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughThe release workflow now targets ChangesRelease workflow transition
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![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: 6414d0b7b6
ℹ️ 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".
| entries under the sections they belong to rather than compressing the PR into | ||
| a single line. The `User-facing changes` and `Breaking changes` headings of | ||
| the PR body are usually already itemized this way. | ||
| - Omit PRs with no user-facing effect (the author wrote "None", or the diff shows |
There was a problem hiding this comment.
When a normal non-breaking feature follows the new template, it provides a substantive User-facing changes section and writes None under Breaking changes. This unconditional “the author wrote None” rule can therefore discard the whole PR as internal, systematically removing non-breaking features and fixes from the PR-sourced release notes. Treat None as applying only to its individual heading and omit the PR only when all relevant sections indicate no user-facing effect. .agents/agents.mdL105-L107
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e2c2f4c. You are right that the rule as written would have discarded every ordinary feature PR, since those write a real user-facing section and "None" under breaking changes. A "None" is now explicitly scoped to the heading it sits under, and a PR is omitted only when every heading says None or the diff shows the change is purely internal.
| given. It is **not** always `master`: feature work lands on `dev` and | ||
| pre-releases are tagged there (see the release docs), so scoping to `master` |
There was a problem hiding this comment.
When dev is selected for a pre-release as now recommended, step 2 still ignores every aN, bN, and rcN tag and can emit only a final vX.Y.Z tag. For example, after v0.2.0b1 it still uses the last stable tag as its lower bound and proposes v0.2.0 rather than v0.2.0b2, both repeating already-published pre-release notes and risking a stable tag from unreleased dev code. The skill needs pre-release version/series handling before this path is advertised.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e2c2f4c. Step 2 now checks the target branch for a pre-release tag newer than the latest stable one before computing anything: if there is one it becomes the lower bound for step 3, so already-published pre-release notes are not repeated, and the next tag continues that series rather than jumping to the stable version. Agreed this only became reachable because step 3 now recommends drafting from dev.
| 2. Create task worktrees under the repository root at `worktrees/{slug}`. Do not create task worktrees under `.agents/worktrees`, even if the current shell starts there. | ||
| 3. Keep commits focused (one logical change per commit where possible). | ||
| 4. Use pull requests to merge to `master`. | ||
| 4. Open pull requests against `dev`, the integration branch, not `master`. `dev` is merged to `master` at release time. Basing a PR on `master` also serves the older pull request template, which lacks the release-note sections. |
There was a problem hiding this comment.
The new canonical workflow sends PRs to dev, but the published docs/contributing/general_guidelines.qmd lines 8–9 still tell contributors to merge feature branches directly into master. Human contributors following that page will continue choosing the base branch that this line says serves the old template, defeating the release-note capture this change depends on; update the contributor documentation in the same change. .agents/agents.mdL89-L89
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e2c2f4c. docs/contributing/general_guidelines.qmd now says feature branches merge into dev, with dev merged to master at release time, matching the agent guide.
| 2. Create task worktrees under the repository root at `worktrees/{slug}`. Do not create task worktrees under `.agents/worktrees`, even if the current shell starts there. | ||
| 3. Keep commits focused (one logical change per commit where possible). | ||
| 4. Use pull requests to merge to `master`. | ||
| 4. Open pull requests against `dev`, the integration branch, not `master`. `dev` is merged to `master` at release time. Basing a PR on `master` also serves the older pull request template, which lacks the release-note sections. |
There was a problem hiding this comment.
GitHub loads a repository's automatic pull-request template from its default branch, not from the PR's selected base branch. Since this repository's default remains master, merging this change only into dev means PRs opened against dev will still receive master's old template until the next dev-to-master merge, so the PRs needed for the first release after retiring the changelog will lack the new release-note sections. Land the template on the default branch or change the repository default before relying on it. .agents/agents.mdL105-L107
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Partly taken, with a caveat worth recording. The claim in agents.md that basing a PR on master serves the older template is removed in e2c2f4c, because I could not establish it: this review says GitHub loads the template from the default branch, an independent review of the same change said it loads from the base branch, and the two templates are byte-identical on master and dev right now, so nothing in the repo settles it. Rather than assert either, agents.md now just directs PRs at dev without the rationale. The operational point stands regardless: whichever branch serves it, the new sections are fully in effect once dev merges to master.
| ## Draft the release notes | ||
|
|
||
| Compare the merged changes since the previous release and group user-facing changes into a short changelog. The changelog should usually include these sections: | ||
| DASCore keeps no changelog in the repository; the release notes *are* the changelog, and they are written from the pull requests merged since the previous tag. Scope them to the branch the release is cut from, which is `dev` for a pre-release and for any work not yet merged down to `master`. Each PR carries its own summary under the `User-facing changes` and `Breaking changes` headings of the [pull request template](https://github.com/DASDAE/dascore/blob/dev/.github/pull_request_template.md), so drafting the notes mostly means collecting and grouping those. The release notes should usually include these sections: |
There was a problem hiding this comment.
For the first release after this change, the dozens of deleted unreleased entries describe PRs that were merged before the new body headings existed. This public workflow now claims each PR carries its own summary and presents the agent skill as optional, but it never gives a human maintainer the skill's git show recovery command; following this page or GitHub's generated notes therefore omits the richer curated record from that release. Add the one-time recovery step here or retain the entries until they have been published. .agents/agents.mdL105-L107
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 4ac3246. The release page now carries the recovery step itself rather than leaving it only in the skill. It is also no longer the one-liner using git log -1, which breaks across a merge commit: the page now says to find the commit that reduced the changelog to a stub and read the revision before it.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #864 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 177 177
Lines 20153 20153
=========================================
Hits 20153 20153
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
- Treat a None as scoped to its own heading; a non-breaking feature writes a real user-facing section and None under breaking changes, and must still reach the notes. - Handle pre-release tags in the version step, which drafting from dev makes reachable: use the pre-release as the lower bound and continue its series. - Point the public branching guidance at dev, matching the agent guide. - Give the release doc the same one-time changelog recovery command the skill has. - Drop the claim about which branch serves the PR template; reviewers disagreed and the repo holds no evidence either way.
# Conflicts: # docs/changelog.qmd
|
@coderabbitai review |
|
# Conflicts: # docs/changelog.qmd
The policy was only a convention in agents.md and the PR template, which is exactly the kind of rule that decays. tests/test_changelog.py holds the page to a stub: it must exist (the URL is published), link to the releases page, say that each pull request describes its own changes, and carry no list items, no sections, and little prose. Each failure message states the policy and points at the PR template, so whoever trips it learns where the text belongs.
coderabbitai
Bot
added
the
documentation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 @.agents/agents.md:
- Line 19: Update the setup flow’s branch-fetching and base-branch commands to
use origin/dev instead of master, while preserving the existing worktree setup
behavior.
In @.agents/skills/draft-release/SKILL.md:
- Around line 40-57: Reorder the release workflow so `<target>` is requested or
resolved before step 2’s pre-release detection. In the pre-release logic,
consider only tags reachable from `origin/<target>` when selecting the newer
series and lower bound; keep step 3’s PR scope based on that same target branch.
In `@tests/test_changelog.py`:
- Around line 71-76: Update test_explains_where_changes_are_described to assert
the changelog’s release-note policy linking each pull request to its own
described changes, rather than only checking for the unrelated substring “pull
request.” Preserve the existing changelog_text fixture and policy failure
context while validating the required relationship between pull requests and
release notes.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f15986b6-bf62-4e1e-b1ff-383119fa500c
📒 Files selected for processing (8)
.agents/agents.md.agents/skills/draft-release/SKILL.md.github/pull_request_template.mddocs/changelog.qmddocs/contributing/general_guidelines.qmddocs/contributing/publish_a_new_release.qmdscripts/_templates/_quarto.ymltests/test_changelog.py
| 2. Create task worktrees under the repository root at `worktrees/{slug}`. Do not create task worktrees under `.agents/worktrees`, even if the current shell starts there. | ||
| 3. Keep commits focused (one logical change per commit where possible). | ||
| 4. Use pull requests to merge to `master`. | ||
| 4. Open pull requests against `dev`, the integration branch, not `master`. `dev` is merged to `master` at release time. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Update the setup command to use dev.
Line 19 makes dev the integration branch. Line 28 still pulls master. New worktrees can therefore start without changes already merged into dev.
Update the setup flow to fetch and base work on origin/dev.
🤖 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 @.agents/agents.md at line 19, Update the setup flow’s branch-fetching and
base-branch commands to use origin/dev instead of master, while preserving the
existing worktree setup behavior.
| - Pre-releases break both of these rules, and drafting from `dev` (step 3) is | ||
| exactly when they occur. Before computing anything, check whether the target | ||
| branch carries a pre-release tag (`aN`, `bN`, `rcN`) newer than the latest | ||
| stable one. If it does: the lower bound for step 3 is that pre-release tag, not | ||
| the last stable release, or the notes will repeat what the pre-release already | ||
| published; and the next tag continues the same series (`v0.2.0b1` → | ||
| `v0.2.0b2`), or finalizes it to `vX.Y.Z` only when the caller says the series | ||
| is ending. Ask which is intended rather than assuming the stable tag. | ||
|
|
||
| 3. Collect merged PRs since the last release: | ||
| - Use the previous release tag identified in step 2 as the lower bound. | ||
| - Define PR scope as changes reachable in `last_release_tag..origin/master` | ||
| (or `..origin/<default_branch>` if default branch is not `master`). | ||
| - Define PR scope as changes reachable in `last_release_tag..origin/<target>`, | ||
| where `<target>` is the branch the release will be cut from. Ask if it was not | ||
| given. It is **not** always `master`: feature work lands on `dev` and | ||
| pre-releases are tagged there (see the release docs), so scoping to `master` | ||
| silently omits everything not yet merged down. Sanity-check the choice before | ||
| drafting — if `git rev-list --count last_release_tag..origin/<target>` is far | ||
| larger than the count against `origin/master`, `dev` is the branch you want. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Resolve <target> before selecting a pre-release tag.
Step 2 needs the target branch, but step 3 asks for it later. Ask for <target> before step 2. Then consider only pre-release tags reachable from origin/<target>.
Without this order, a tag from another branch can set the version and lower bound. The drafted notes can then omit or repeat changes.
🧰 Tools
🪛 LanguageTool
[style] ~41-~41: Consider an alternative for the overused word “exactly”.
Context: ..., and drafting from dev (step 3) is exactly when they occur. Before computing anyth...
(EXACTLY_PRECISELY)
🪛 SkillSpector (2.5.1)
[info] 110: [EA3] Scope Creep: Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.
Remediation: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
(Excessive Agency (EA3))
🤖 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 @.agents/skills/draft-release/SKILL.md around lines 40 - 57, Reorder the
release workflow so `<target>` is requested or resolved before step 2’s
pre-release detection. In the pre-release logic, consider only tags reachable
from `origin/<target>` when selecting the newer series and lower bound; keep
step 3’s PR scope based on that same target branch.
Replace the six invariant checks with one comparison against the expected text. Pinning the contents outright is both simpler and stricter: it fails on any edit, not only on the shapes a rule anticipated.
The sdist grafts tests but ships only docs/LICENSE, so the directory exists there while the page does not: keying the skip on the directory made the test fail in an sdist rather than skip. Key it on docs/index.qmd, which is present only with the real docs tree. Not keyed on changelog.qmd itself, since deleting the page must fail rather than silently skip.
One required section instead of two, named for what it becomes. Each bullet carries a Keep-a-Changelog category (added, changed, deprecated, removed, fixed, security) and is marked **breaking** only when it can break code written against the last released version -- breakage confined to unreleased dev work is invisible to users and marking it would train people to ignore the marker. CheckPRChangelog enforces the section rather than leaving it a convention; the parser is a script so it can be tested, and the body reaches it through the environment rather than shell interpolation. The draft-release skill now reads these categories instead of re-deriving them, and emits Breaking Changes first followed by the six category sections.
|
✅ Documentation built: |
'- changed: **breaking** x.' parsed as an ordinary changed entry whose text happened to start with bold words, so an author who put the marker one position off got a green check and their breaking change would have reached the release notes unmarked -- the exact failure the marker exists to prevent. It is now rejected with a message saying where the marker belongs. Categories are matched case-insensitively in the same pass: a capitalized 'Added:' is a harmless slip and failing CI over it teaches nothing.
coderabbitai
Bot
removed
the
documentation
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 @.github/scripts/check_pr_changelog.py:
- Around line 76-96: Update the Changelog validation flow around the
section-processing logic to validate every non-empty, uncommented line against
ENTRY rather than filtering through _ANY_BULLET; preserve the special case where
the entire section is “none” and keep malformed-entry and stray-marker reporting
intact. Add regression cases in tests/test_changelog.py covering prose before
and after a valid categorized entry.
In `@tests/test_changelog.py`:
- Around line 55-59: Update test_contents_are_unchanged to compare the raw
contents read from _CHANGELOG_PATH directly with _EXPECTED, removing strip()
from both sides so leading and trailing whitespace changes are detected.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9f52a33d-72fc-405d-9700-1273cab8deff
📒 Files selected for processing (7)
.agents/agents.md.agents/skills/draft-release/SKILL.md.github/pull_request_template.md.github/scripts/check_pr_changelog.py.github/workflows/check_pr_changelog.ymldocs/contributing/publish_a_new_release.qmdtests/test_changelog.py
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/contributing/publish_a_new_release.qmd
| bullets = [x for x in section.splitlines() if _ANY_BULLET.match(x.strip())] | ||
| if not bullets: | ||
| return ["The Changelog section has no entries.", _HELP] | ||
| problems = [x.strip() for x in bullets if not ENTRY.match(x.strip())] | ||
| if problems: | ||
| listed = "\n".join(f" {x}" for x in problems) | ||
| return [f"These Changelog entries are malformed:\n{listed}", _HELP] | ||
| misplaced = [ | ||
| x.strip() | ||
| for x in bullets | ||
| if _STRAY_MARKER.search(ENTRY.match(x.strip()).group("text")) | ||
| ] | ||
| if misplaced: | ||
| listed = "\n".join(f" {x}" for x in misplaced) | ||
| return [ | ||
| "These entries carry '**breaking**' in their text, where it is read " | ||
| f"as prose rather than as the marker:\n{listed}\n" | ||
| "Put it directly after the category, before the colon, e.g. " | ||
| "'- changed **breaking**: ...'.", | ||
| ] | ||
| return [] |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Reject non-entry text in the Changelog section.
The validator filters to bullet lines before it validates ENTRY. A section with a valid categorized entry and arbitrary prose passes CI. Require every non-empty, uncommented line to match ENTRY, unless the whole section is none.
.github/scripts/check_pr_changelog.py#L76-L96: validate all non-empty section lines instead of filtering to_ANY_BULLET.tests/test_changelog.py#L103-L128: add regression cases with prose before or after a valid categorized entry.
📍 Affects 2 files
.github/scripts/check_pr_changelog.py#L76-L96(this comment)tests/test_changelog.py#L103-L128
🤖 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 @.github/scripts/check_pr_changelog.py around lines 76 - 96, Update the
Changelog validation flow around the section-processing logic to validate every
non-empty, uncommented line against ENTRY rather than filtering through
_ANY_BULLET; preserve the special case where the entire section is “none” and
keep malformed-entry and stray-marker reporting intact. Add regression cases in
tests/test_changelog.py covering prose before and after a valid categorized
entry.
| def test_contents_are_unchanged(self): | ||
| """The page must match the expected stub exactly.""" | ||
| assert _CHANGELOG_PATH.exists(), f"{_CHANGELOG_PATH} is missing. {_POLICY}" | ||
| contents = _CHANGELOG_PATH.read_text(encoding="utf-8") | ||
| assert contents.strip() == _EXPECTED.strip(), _POLICY |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Compare the stub without trimming.
strip() accepts added leading or trailing whitespace. This conflicts with the exact-content requirement. Compare the raw file contents with _EXPECTED.
Proposed fix
- assert contents.strip() == _EXPECTED.strip(), _POLICY
+ assert contents == _EXPECTED, _POLICY📝 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.
| def test_contents_are_unchanged(self): | |
| """The page must match the expected stub exactly.""" | |
| assert _CHANGELOG_PATH.exists(), f"{_CHANGELOG_PATH} is missing. {_POLICY}" | |
| contents = _CHANGELOG_PATH.read_text(encoding="utf-8") | |
| assert contents.strip() == _EXPECTED.strip(), _POLICY | |
| def test_contents_are_unchanged(self): | |
| """The page must match the expected stub exactly.""" | |
| assert _CHANGELOG_PATH.exists(), f"{_CHANGELOG_PATH} is missing. {_POLICY}" | |
| contents = _CHANGELOG_PATH.read_text(encoding="utf-8") | |
| assert contents == _EXPECTED, _POLICY |
🤖 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 `@tests/test_changelog.py` around lines 55 - 59, Update
test_contents_are_unchanged to compare the raw contents read from
_CHANGELOG_PATH directly with _EXPECTED, removing strip() from both sides so
leading and trailing whitespace changes are detected.
The same rules were spelled out in five places: the PR template, agents.md, the release doc, the skill, and the checker's help text. Contributing guidelines now hold the one definition, under 'Changelog entries', and everything else points at it. The release doc keeps only the section order, which is its own concern. Prose added by this branch drops from 168 lines to 82.
coderabbitai
Bot
added
CI
The dascore.org link only resolves once a release rebuilds the stable docs, so until then a contributor on dev following it lands on a page without the section. Name the file path first and keep the URL beside it.
It loads every session, so its size is a recurring token cost. Same rules, stated as a checklist rather than prose, with rationale dropped: 534 words to 324. No rule removed.
Same procedure, fewer words: merge the numbered steps' restated context, drop the per-command prose, and fold the Notes back into the output example.
1 participant
Description
docs/changelog.qmdhas grown to 69 unreleased entries, many of them paragraph-length. Every PR edits the same file, so it conflicts constantly — this PR has had to resolve two — and it duplicates the releases page, which the page's own first line already points at.This retires it. The page becomes a five-line stub pointing at the releases page, kept only so the published
changelog.htmlURL keeps resolving; the sidebar links to GitHub Releases directly. User-facing information moves to the PR that makes the change, via newUser-facing changesandBreaking changessections in the template, and thedraft-releaseskill assembles the release notes from those PRs at tag time.tests/test_changelog.pyenforces this rather than leaving it a convention: the page must exist, link to the releases page, say that each PR describes its own changes, and carry no list items, no sections, and little prose. Each failure message states the policy and points at the PR template.Review turned up three bugs in the release skill, which this change makes load-bearing:
origin/master, but work lands ondevand pre-releases are tagged there. 115 of the 128 commits sincev0.1.20are absent from master, so a run today would have produced a nearly empty changelog.Bug Fixesand would have shipped as user-facing bug fixes.It also now handles pre-release tags, and points the drafter at the pre-stub changelog in git history, whose curated text for already-merged work is richer than those PR bodies. The release page carries that recovery step too. Finally,
general_guidelines.qmdandagents.mdsaid feature branches merge tomaster; both now saydev.Changelog
changelog.htmlURL still resolves, to a stub pointing at the same place.Checklist
I have:
I have (if applicable):
Summary by CodeRabbit
Documentation
devintegration branch.New Features
Tests