Release notes are the one document a product team writes that has a send button attached. Everything else is published and waited on. This one goes out.
Which makes the send the interesting part, and almost nobody writes about it. Most pages on release notes are about wording. This one is about who receives them, because that is the question that decides whether writing them was worth the hour.
What are release notes?
Release notes are a short written record of what changed in one release, addressed to the people who use the thing that changed. One release, one document, written after the work rather than before it.
That last part is what separates them from a roadmap entry. A roadmap entry is a promise about the future and it can be wrong without anybody lying. A release note is a description of the past, and it either matches what shipped or it does not.
They are usually grouped by kind. New, improved, fixed, deprecated, and a short note on anything that needs the reader to act. The template on this site sets those out in full and is free to copy, so this page will not repeat it.
There is a working version of this on the demo board, which is open without an account.
How are release notes different from a changelog?
A release note is one document. A changelog is the page they accumulate on, in reverse date order, and it is a place rather than a document.
The distinction sounds pedantic until you try to write both with one habit, at which point it decides your tooling. Changelog against release notes is the longer answer, including the awkward part about which of the two your customers actually owe you.
Who actually gets told when you publish them?
Fewer people than you think, on every tool including ours, and it is worth knowing the shape of the gap before you count on the send.
The mechanism on our side is simple enough to state in one line. A release gathers the cards that finished, finds who voted for them, and writes each of those people a note about their own ones.
The changelog page sets that out properly, including what happens when two of your requests land in the same release.
What that page does not dwell on, and what nobody in this category writes down, is the three ways delivery quietly does not happen.
The first is identity. Somebody who voted on your public board without signing up has no address behind them, so they are not written to and cannot be. On a board that is mostly anonymous traffic, that is most of your voters.
We would rather that than harvest an address from somebody who deliberately withheld one, but it does mean the email is a nudge to a slice rather than an announcement to everybody.
The second is volume. Any one address gets at most one product email a day from us, across every kind of message we send. If a customer already had something from your board that morning, this one is dropped, and because the release has already been marked as announced, it is not tried again tomorrow.
The third is preference. Each kind of message has a switch a recipient can turn off, and turning it off is silent from your side. You will not see a bounce, because nothing bounced.
Add those together and the honest summary is that the email reaches a subset of a subset.
That is a reason to treat the email as the nudge and the published page as the record rather than a reason to skip release notes, because the page has none of those three problems and it is the thing a customer finds in six months when they go looking for when did this change.
What happens if nothing in the release is finished?
Nothing is sent, to anybody, and that is deliberate rather than a bug.
A release only counts the cards sitting in the Completed column. Pull together a release out of work in progress and publish it, and no email leaves the building, because a release with no finished work has nothing to announce and a note saying so is worse than silence.
It is a small behaviour and it catches people, so it is worth saying out loud. If you published and nobody heard anything, check the column the cards are in before you check anything else.
14 days, a card at signup, then $9 or $39 a month.
What makes a release note worth reading?
Naming the person who asked. That is the whole trick, and it is available to you exactly once, at the moment you ship.
A release note that says improved performance in the dashboard is a line nobody finishes. A release note that says the dashboard loads in under a second now, which four of you asked for in March, is read to the end by at least four people who will remember it.
The second one costs no more words than the first. It costs a link back to where the request came from, which is why the notes are easier to write when the requests live somewhere you can look them up.
Past that, the rules are unglamorous. Write for the person using the product rather than the person who built it. Say what is different rather than what was done. Put the thing that needs action first and the polish last. And keep it short enough that skipping it feels lazy rather than sensible.
Why do release notes stop getting written?
Because they are a second job wearing the clothes of a small one, and the cost is not the writing.
The cost is remembering. Two weeks after a release, nobody can reconstruct which of the eleven merged branches were customer visible, so the note either gets written from a commit log, which reads like a commit log, or it does not get written at all. Most teams stop somewhere around release four.
The fix is not discipline. It is making the note a side effect of work you were doing anyway. When a card moves to Completed on the board, the card already carries the heading a customer wrote, the discussion underneath it, and the list of people who wanted it.
At that point the release note is an editing job rather than a research job, and editing jobs survive a busy month.
How do you publish release notes without it becoming a job?
Group the finished cards into a release, edit the headings into sentences a customer would recognise, and publish. The announcement and the public page are the same action.
There is no second system to keep current, which is the failure this whole category exists to fix. Twelve releases written twice, once as a team wrote it and once as the customer needed it, is the shortest way to see what editing the headings means.
Our changelog is the page the releases land on, and the widget puts the same content inside your own product so the people who never visit your site still see it.
It is nine dollars a month on the smaller plan with the board, the roadmap and the changelog included, and a card is required for the fourteen day trial. The pricing page has the rest of it.
