• Fetch and checkout the web/release-x.y branch that was pushed by the Release Manager
    • 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 issues 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
    • 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.
  • 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 issue for fixed problems and changes that are well justified in GitLab
    • Put the period before issue number
      • "Bla bla. ([!tails_ticket 1234])"
  • Create a merge request in GitLab that targets the web/release-x.y branch and assign the Release Manager as the reviewer
  • Prepare a tweet with highlights:

    • Tails x.y is out:

      https://tails.net/news/version_x.y/

      It bla bla bla, and more.

    • Add it as a comment to the issue for the release notes.
  • If we release new major features ("New features" section), schedule tweets in the future to let the world know about it, even months after we release them.
    • Write a Tweet, for example:
      • Did you know? You can xxx in Tails, since $MON (Tails $VERSION).
      • Link to our documentation about the feature.
      • Add a picture, for example a screenshot from the release notes or the documentation.
    • Schedule tweets using TweetDeck.
      • For example, 3 tweets across 6 months for new cool stuff, and even a few more tweets for very important features.
      • Spread tweets across 12:00 and 18:00 UTC to have a good coverage in Europe, the US (East and West coast), and a bit of South-East Asia.
      • TweetDeck displays the time as it is on your computer, so UTC if you are in Tails.