A changelog that keeps up with every release you ship.
DevRelay turns each GitHub release into a changelog entry grouped the way readers scan it: Breaking and Deprecated first, then Added, Improved and Fixed. Written from the diff, checked against it, exported as Markdown.
Go SDK v2.8.0: Add Stream() for incremental query results
What's new
- Stream() returns *Rows backed by a server-side cursor.
- Rows are yielded as the server produces them, so large result sets no longer need to be buffered in memory.
- Reads pause when the consumer is slower than the network (backpressure).
- Calling rows.Close() or cancelling ctx releases the cursor.
Example
rows, err := db.Stream(ctx, "SELECT * FROM events")
if err != nil {
return err
}
defer rows.Close()
for rows.Next() {
var e Event
if err := rows.Scan(&e.ID, &e.Payload); err != nil {
return err
}
}
return rows.Err()- 5 headings
- Breaking first, Fixed last
- Reads your conventions
- commits and labels
- Markdown
- for any changelog page
Your changelog is the first thing users check and the last thing anyone updates.
Everyone agrees it matters. Nobody has the afternoon.
A commit log isn't a changelog
“fix: handle nil in resolver” means something to the person who wrote it. Your users need to know what broke for them and whether it's fixed.
It's always a release behind
The entry waits for someone with time to read every merged pull request, so it gets written in a rush or not at all.
Everything looks equally important
A breaking change sits between two typo fixes. The user who needed to see it finds out in production.
From tagged release to a changelog entry you'd have written yourself.
It reads what shipped, sorts it, writes it and checks it. You approve and export.
Reads the release, not the commit log
feat!: / BREAKING CHANGE / semver-major → Breaking deprecat* in title or label → Deprecated fix: / hotfix: / bug label → Fixed perf: / perf label → Improved otherwise → classifier
Sorts each change by kind
Keeps small things small
Checks the entry against the code
Writes a release announcement for big releases
### v2.8.0
#### Added
- Stream() for incremental query results.Exports as Markdown
One line per change, under the heading readers look for.
Breaking changes and deprecations go first, because they're the lines that cost your users an afternoon if they miss them. Each kind has its own line shape, so a fix says what users saw and a performance change only shows numbers the evidence actually has.
- BreakingWhat changes. What to do.- --seed is removed; use --data-sample. Migration guide
- DeprecatedWhat, removed in which version. The replacement.- --seed, removed in 4.0. Use --data-sample.
- AddedThe capability: what you can do. A link.- Database branches: every PR gets its own database. Docs
- ImprovedWhat, and how it's better. Numbers only if measured.- Branch creation: 41s → 6s (p95, 10 GB database).
- FixedThe symptom users saw, now fixed.- acme branch create no longer hangs on databases over 50 GB.
Every entry shows its evidence before you approve it.
Open a draft in the inbox to see the checks it passed and the evidence behind each claim.
Questions about the changelog.
01Does it write to CHANGELOG.md or open a pull request?
Not yet. You approve the entry in the inbox and export it as Markdown, then paste or commit it wherever your changelog lives. Export is on the DevRelay plan.
02Do we need to use Conventional Commits?
No. If your pull request titles follow Conventional Commits (feat!:, fix:, perf:) or you use labels like breaking, bug or perf, DevRelay reads them first. Without them, a classifier decides the change kind from the change itself.
03Is this the same as GitHub's auto-generated release notes?
No. GitHub's generator lists merged pull requests by title and author, grouped by labels you configure. DevRelay writes a line per change for the people using your product, from the diff and linked issues, and checks each line against that evidence.
04Will it put unreleased work in the changelog?
No. Changes are held until a GitHub release ships them, or until they merge into your release branch if the repo is set to branch mode.
05What does it use for the version heading?
The product and the version of the GitHub release that shipped the change, such as Go SDK v2.8.0.
06Can we change how entries are written?
Yes. The brand brain has a changelog instruction field for house rules, and DevRelay learns from the edits you make before approving.
Stop writing the changelog the night before the release.
Connect a repo. The next release comes with its changelog entry, grouped and checked, waiting for your yes.
No credit card · Nothing posts without your approval