docs: keep a CHANGELOG.md, with one entry file per PR

Release notes were written by hand on GitHub at tag time, so the contents
of a stacked release had to be pieced together from every PR, and output
changes that scripts and agents rely on were easy to miss.

- CHANGELOG.md backfills every published release (0.2.0 to 0.4.0) from its
  GitHub notes, verbatim.
- A PR adds changes/unreleased/<branch-name>.md instead of editing
  CHANGELOG.md, so stacked PRs never conflict. changes/README.md gives the
  sections, including Output Changes for JSON, MCP and error-code changes.
- scripts/changelog.sh: `check` validates entries and CHANGELOG.md,
  `release X.Y.Z` folds the entries into a new section (ordered by PR), and
  `notes X.Y.Z` prints a section as GitHub release notes.
- The release workflow sets the GitHub notes from the tag's section.
- New flake check `changelog` runs scripts/changelog-test.sh; both scripts
  are shellchecked.
- Entries for 0.5.0: #73, #74, #75, #78, #79, #80, #81 and this PR.

Claude-Session: https://claude.ai/code/session_01RqPPVeVDrnLoP7NUZmLRxY
This commit is contained in:
Rasyidan Akbar F. 2026-11-04 19:48:58 +07:00
commit 809966925e
21 changed files with 942 additions and 13 deletions

View file

@ -116,17 +116,22 @@ Release order:
1. Bump the version together in `Cargo.toml` (workspace version and the
`idx-core` dependency pin), `package.json`, and `npm/idx-mcp/package.json`.
A version number can never be republished.
2. Push the tag, or run the workflow for an existing tag.
3. Publish the crates from the tagged commit, dependency first:
2. In the same release PR, run `scripts/changelog.sh release X.Y.Z` (the date
defaults to today, UTC). It folds `changes/unreleased/` into a new
`CHANGELOG.md` section in the fixed section order, ends it with the
`**Full Changelog**` compare link, and deletes the entries. Add a
`changes/unreleased/summary.md` first for a one-line opener, such as an
upgrade note when a fix is urgent. Edit the section by hand if needed;
`scripts/changelog.sh notes X.Y.Z` prints it as GitHub will show it.
3. Push the tag, or run the workflow for an existing tag. The workflow
attaches the binaries and sets the release notes to the tag's
`CHANGELOG.md` section; a tag whose `CHANGELOG.md` lacks its version keeps
the notes it has.
4. Publish the crates from the tagged commit, dependency first:
`cargo publish -p idx-core`, then `-p idx-cli` and `-p idx-mcp`.
4. Confirm the release has all eight binaries plus `SHA256SUMS`, then write
its notes (`gh release edit vX.Y.Z --notes-file <file>`; the workflow
creates the release without them). Open with a one-line upgrade note when
a fix is urgent, then `## New Features`, `## Bug Fixes`, `## Improvements`
(and `## Testing` or `## Docs` when useful): one user-facing sentence per
item, ending with the PR or issue numbers, e.g. `(#46)`. Omit empty
sections, and end with
`**Full Changelog**: https://github.com/0xrsydn/idx-cli/compare/<previous>...<this>`.
5. Run `npm publish` in the repo root and in `npm/idx-mcp/` from the tagged
5. Confirm the release has all eight binaries plus `SHA256SUMS` and the notes.
To fix the notes later, edit `CHANGELOG.md` and run
`gh release edit vX.Y.Z --notes-file <(scripts/changelog.sh notes X.Y.Z)`.
6. Run `npm publish` in the repo root and in `npm/idx-mcp/` from the tagged
commit. The account has two-factor auth, so npm asks for a browser
approval or `--otp=<code>`.