• Create a branch based on the development branch for this release
    • web/nnnnn-x.y-release-notes
    • Copy template from contribute/how/documentation/release_notes/template.mdwn to news/version_x.y.mdwn
    • Replace placeholders in template
  • Gather information about changes
  • Write the draft
    • As a rule of thumb, get inspiration from all these data sources but write new sentences yourself. Changelog and release notes are written for different audiences and for different purposes.
    • Focus on what is the benefit for the user (if any, if relevant, and not to wordy).
      • For example: Automatically save the database of KeePassX after every change to prevent data loss when shutting down.
    • Our release notes should satisfy a diverse audience of both very technical and less technical users. As such, it's all-right to include more technical language, for example for security benefits that are not visible, as long as:
      • Changes that are noticable by less technical users are still understandable by them.
      • What we are describing in non-technical language is understandable by more technical users.
      • We point to more technical sources like tickets and design documents.
      • Technical items are less proheminent.
      • For example: Harden our firewall by rejecting RELATED packets and restricting Tor to only send NEW TCP syn packets. (##11391)
    • Use full sentences for major changes ("We installed", "You can")
    • Use present tense without subject for minor changes ("Upgrade", "Fix")
    • Mention updates as "Update Xyz to [1.2.4]."
      • Mention previous version if we skipped some "Update Xyz from 1.0.0 to [1.2.3]."
      • Link to release notes if any, or changelog
      • For Linux upgrades add "This should improve the support for newer hardware (graphics, Wi-Fi, etc.)"
    • Order items to put the most visible, less technical, and most popular items first while not being afraid of putting more technical items as well down the list.
    • Document known issues
    • Update the meta title directive.
    • Update the meta date directive.
    • Make sure there's an announce tag to have an email sent to the news mailing list.
  • Update the known issues page:
    • Add regressions brought by the new release.
    • Remove older known issues that are fixed by the new release.
  • Format
    • Link to ticket for fixed problems and changes that are well justified in Redmine
    • Put the period before ticket number
      • "Bla bla. ([!tails_ticket 1234])"
  • Prepare a tweet with highlights:
    • Tails x.y is out: https://tails.boum.org/news/version_x.y, bla bla bla, and more.
    • Add it as a comment to the ticket for the release notes.