Changelog

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 · Release with PR #318GroundingRelease statusBrand

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.
Unedited draft · Tidydesk sample workspace
4 headings
New, Improved, Fixed, Changed
Reads your conventions
commits and labels
Hosted page
RSS, JSON feed and widget
Why changelogs fall behind

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.

How it works

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.

01

Reads the release, not the commit log

For each release DevRelay collects the pull requests it ships, their diffs, linked issues and the release notes. The entry is written from that evidence, so it describes what users get rather than what the commits were called.
feat!: / BREAKING CHANGE / semver-major  → Changed
deprecat* in title or label              → Retiring
fix: / hotfix: / bug label               → Fixed
perf: / perf label                       → Improved
otherwise                                → classifier
02

Sorts each change by kind

Conventional Commits and labels decide first. When they don't say, the classifier scores whether the change is a bug fix, a performance change or a breaking change.
03

Keeps small things small

Low-priority changes go in the changelog and nowhere else, so a typo fix never becomes a tweet. Security-sensitive changes are held for a person to decide and never drafted automatically.
04

Checks the entry against the code

The same hard gates as every draft: no claims without evidence, no feature names or numbers the change doesn't contain, no beta features called GA. Numbers appear only when the evidence has them.
05

Writes a release announcement for big releases

When a release has something worth announcing, you also get the announcement: a section for each notable change, written from that change's evidence, with a usage example when the change has one. A maintenance-only release gets none.
## Tidydesk app update: Send later for replies

### New

- Send later: Schedule replies for tomorrow morning, …
06

Publishes to your changelog page

Approve the entry and publish it, now or at a scheduled time, to a changelog page DevRelay hosts at updates.devrelay.so or your own subdomain, with RSS and JSON feeds and a What's new widget for your app. Or export it as Markdown for a help center or CMS. The changelog isn't committed to your repository; docs updates are the drafts that open a pull request.
Entry shape

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.

Heading, line shape, exampleIllustrative product
  • 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.
Review

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.

app.devrelay.so/inbox
DevRelay inbox showing a draft with its hard-gate results and rubric scores
FAQ

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