# Release notes template Copy this file, delete the guidance lines starting with a greater than sign, and fill in what shipped. Sections you do not need should be deleted rather than left empty, because a heading with nothing under it reads as a document somebody abandoned. Categories are in the order a reader needs them, not the order you did the work. --- ## 2.4 > Replace with your version or release name. If you do not use version numbers, a date works. > Released 9 September 2026. > One or two sentences saying why this release matters, written for somebody who does not know your > internal vocabulary. Delete this paragraph if the list below speaks for itself. ### Breaking changes > Anything that will stop working, or work differently, for somebody who changes nothing. This > section is first because that is the question a reader of release notes actually arrived with. > Say what breaks, when, and what to do instead. Delete the section if nothing breaks. - The v2 API stops accepting requests on 1 November. Move to v3, which takes the same fields. ### New features > Things a person can now do that they could not do before. Write the sentence from their side, not > from the module's side. - Search the board by heading, tag or the name of the person who asked. - Export your voters and what they pay as a CSV. ### Improvements > Something that already existed and is now better. Say what changed, not that it was optimised. - The board loads in about half the time on projects with more than a thousand requests. ### Bug fixes > What was wrong, in the words somebody would use to report it. Skip anything nobody outside the > team could have noticed. - The vote count no longer drifts after two requests are merged. ### Security > Give this its own heading rather than burying it in fixes, even when the entry is one line. > Say what you changed. Do not describe the exploit. - Session tokens are rotated when a password or email address changes. --- ## Notes on using this **Write the entry when you ship, not when you remember.** The single reason changelogs lapse is that they are a separate document with no owner. If you can make the entry out of work you already tracked, do that instead of keeping a second list in sync. **One line per item.** A release note is not a commit log. If an item needs a paragraph, it probably needs its own post, and the note should link to it. **Tell the people who asked.** A general announcement competes with everything else in an inbox. A message saying the thing you asked for in March has shipped is about them, and it is the only part of this that reliably gets read. This template is published by VoteFirst at https://votefirst.app/en/tools/release-notes-template and may be copied, changed and used commercially with no attribution.