This generates a changelog entry in Markdown, a version heading followed by whichever categories you filled in, each one a proper heading with a bullet list under it. Type what shipped below, separated by commas, and the Markdown builds underneath, ready to paste into CHANGELOG.md or a GitHub release.
Nothing you type leaves this page.
Fill anything in above.
The demo board is open and it asks for no account.
A changelog template in Markdown
Keep a block like this one at the top of CHANGELOG.md, and paste a new block above the last one on every release.
## [2.4] - 2026-10-02
### Added
- Search the board by heading, tag or voter name.
### Changed
- The board loads about twice as fast on projects with a thousand requests.
### Fixed
- Vote counts no longer drift after two requests are merged.
### Security
- Session tokens rotate when a password or email address changes.
Added, Changed, Fixed and Security are four of the six headings Keep a Changelog standardised, with Deprecated and Removed left out here because nothing in the example uses them. A group with nothing under it does not get a heading, in the template above or in the box further up this page.
What makes a release note worth reading?
Three rules, and the box above follows all three so you do not have to remember them.
Breaking changes go first. This is the only one that is not a preference. Somebody opening a release note is asking what is about to stop working, and putting that at the bottom answers it after they have closed the tab.
Empty sections are dropped. Four headings with nothing under three of them reads like a template somebody abandoned. Leave a box blank and its heading does not appear.
One line per item, in plain words. A release note is not a commit log. The useful line says what a person can now do that they could not do yesterday, without the internal name of the module.
How long is a typical changelog entry?
84 words, the median across 16,060 entries on 327 public Canny and Featurebase changelogs read on 3 October 2026. A quarter run 45 words or fewer, a quarter 161 or more, and the median team posts four entries a year.
53.5 percent of those entries carry the label new, 31.3 percent improved and 17.1 percent fixed. Fewer than one entry in five announces a fix. The full measurement, with the file to download.
Why these five categories?
Scanning, not filing. They are the same five VoteFirst's own product uses, so a draft made here pastes straight in.
A fixed set lets somebody scanning a year of entries see the shape of the year, how much was new work, how much was repair, how often something broke on purpose. Free text destroys that the first time a heading reads Bugfix instead of Bug fix, and it will.
These five map onto most of what Keep a Changelog standardised. New features is its Added, Improvements is its Changed, Bug fixes is its Fixed, and Security is the same word on both lists. Breaking changes stays on its own heading instead of folding into Changed, because it is the one line a reader opening a release note needs first.
Is this a release notes generator too?
Yes. The two words describe the same box. Whether you publish the result as one line on a running page or as a document for one release is a decision about where it goes, not about how it is written.
What this is not is a pipeline tool. It does not read a commit range, run in a build or open a pull request. If you want a file to start from instead, the release notes template is plain Markdown. Notes generated from merged pull requests or from a Jira version are walked through step by step for GitHub, GitLab, Jira and Azure DevOps.
VoteFirst keeps a hosted changelog on the same board, and emails the release only to the voters whose own request is in it.