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: New, Improved, Fixed and Changed, in words your users know. Written from the diff, checked against it, published to a changelog page we host for you.
Tidydesk app update: Send later for replies
New
- Send later: Schedule replies for tomorrow morning, Monday morning, or a custom date and time. Edit or cancel them before they’re sent; if your customer replies first, the scheduled reply pauses and the assigned teammate is notified.
- 4 headings
- New, Improved, Fixed, Changed
- Reads your conventions
- commits and labels
- Hosted page
- RSS, JSON feed and widget
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 publish.
Reads the release, not the commit log
feat!: / BREAKING CHANGE / semver-major → Changed deprecat* in title or label → Retiring 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
## Tidydesk app update: Send later for replies
### New
- Send later: Schedule replies for tomorrow morning, …Publishes to your changelog page
One line per change, under the heading readers look for.
Each heading names the change in words your users know, never a version number. Each kind has its own line shape, so a fix says what users saw, a change says what to do, and a performance change only shows numbers the evidence actually has.
- NewThe capability: what you can do. A link.- Shared inboxes: your team answers customer emails from one inbox. Learn more
- ImprovedWhat, and how it's better. Numbers only if measured.- Search: 4s → under 1s (a year of conversations).
- FixedThe symptom users saw, now fixed.- Attachments over 10 MB no longer fail to send from the mobile app.
- ChangedWhat changes. What to do.- Weekly reports now export from Analytics, then Exports. Guide
- RetiringWhat's going away, a date only if known. The replacement.- The old reports page is going away. Use Analytics, then Exports.
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.
01Where does the changelog entry go?
To a changelog page DevRelay hosts for you, at updates.devrelay.so/your-company or a subdomain of your own such as changelog.acme.com, with RSS and JSON feeds, a sitemap and a What's new widget you add to your app with one script tag. You approve each entry in the inbox first. You can also export it as Markdown and paste it wherever your changelog lives. Publishing and export are on the DevRelay plan.
02Does it write to CHANGELOG.md or open a pull request?
No. The changelog goes to your hosted page or a Markdown export, not into your repository. Docs updates are different: on the DevRelay plan, an approved one opens a pull request on your docs repo.
03Can the changelog page look like our site?
Yes. It starts from your brand: logo, colours and fonts picked up from your website. You can change the layout, header, fonts, colours and labels, add custom CSS, and choose whether search engines index it. Every page shows a small “Powered by DevRelay” link in the footer.
04Do 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.
05Is 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.
06Will 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.
07Does the entry show the version number?
No. The heading names the product and the change, such as “Tidydesk app update: Send later for replies”, because most of your users never see a version number. A check fails any draft that names a version or links to GitHub.
08Can 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