See the release schedule.


Export the following environment variables to be able to copy'n'paste the scripts snippets found on this page:

  • version numbers (see release schedule):

    export VERSION=$(dpkg-parsechangelog -SVersion)
    export TAG=$(echo "$VERSION" | sed -e 's,~,-,')
    export PREVIOUS_VERSION=$(dpkg-parsechangelog --offset 1 --count 1 -SVersion)
  • NEXT_MAJOR_VERSION: set to the version number of the next Tails release (e.g. 0.23 when releasing 0.22.1, and 1.3 when releasing 1.2)

  • MAJOR_RELEASE: set to 1 if preparing a major release, to 0 else
  • ISOS: the directory where one stores tails-i386-* sub-directories like the ones downloaded with BitTorrent.
  • ARTIFACTS: the directory where build artifacts (e.g. the .packages file) land.
  • MASTER_CHECKOUT: a checkout of the master branch of the main Tails Git repository.
  • RELEASE_BRANCH: the name of the branch of the main Tails Git repository used to prepare the release (stable or testing).
  • RELEASE_CHECKOUT: a checkout of the branch of the main Tails Git repository used to prepare the release (stable or testing).
  • IUK_CHECKOUT: a checkout of the relevant tag of the iuk Git repository.
  • PERL5LIB_CHECKOUT: a checkout of the relevant tag of the perl5lib Git repository.


The release manager role documentation has more tasks that should be done early enough.

Update Tor Browser preferences

  • update extensions.adblockplus.currentVersion in config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js

Update Icedove preferences

  • update extensions.enigmail.configuredVersion in config/chroot_local-includes/etc/skel/.icedove/profile.default/preferences/0000tails.js

Coordinate with Debian security updates

See Debian security updates.

Select the right branch

What we refer to as the "release branch" (and RELEASE_BRANCH) should be testing for major releases, and stable for point-releases.

Read the remainder of this document from the branch used to prepare the release!


Major release

If we are at freeze time for a major release:

  1. Merge the master Git branch into devel:

     git checkout devel && git merge --no-ff origin/master
  2. Merge each APT overlay suite listed in the devel branch's config/APT_overlays.d/ into the devel APT suite.

  3. Merge the devel Git branch into the testing one:

     git checkout testing && git merge devel

    ... and check that the resulting config/APT_overlays.d/ in the testing branch is empty.

  4. Hard reset the testing APT suite to the current state of the devel one.


If we are at freeze time for a point-release:

  1. Merge the master Git branch into stable:

     git checkout stable && git merge --no-ff origin/master
  2. Merge each APT overlay suite listed in the stable branch's config/APT_overlays.d/ into the stable APT suite.

Common steps for point and major releases

After either of the above sections' steps, reset the release branch's config/base_branch:

echo "${RELEASE_BRANCH}" > config/base_branch && \
git commit config/base_branch -m "Restore ${RELEASE_BRANCH}'s base branch."

Update included files

AdBlock patterns

Patterns are stored in config/chroot_local-includes/etc/tor-browser/profile/adblockplus/.

  1. Boot Tails
  2. Start the tor Browser and open ToolsAddons
  3. Select Adblock Plus in extensions
  4. Open PreferencesFilter preferences…
  5. For each filters, click ActionsUpdate filters
  6. Close the Tor Browser
  7. Copy the .tor-browser/profile.default/adblockplus/patterns.ini from this Tor Browser instance to the config/chroot_local-includes/etc/tor-browser/profile/adblockplus directory in the Tails Git checkout.
  8. Commit:

    git commit -m 'Update AdBlock Plus patterns.' \

Upgrade bundled binary Debian packages

That is: make sure the bundled binary Debian packages contain up-to-date localization files.

For each bundled Debian package, cd into the package's root directory (e.g. a checkout of the whisperback repository), and then run the import-translations script that is in the main Tails repository. For example:

cd whisperback

If the import-translations script fails to import translations for the current package, manually copy updated PO files from the Transifex branches of git:// (e.g. whisperback_completed) instead. In this case, skip PO files for translation teams that use Git.

Add and commit.

Then check the PO files:


Correct any displayed error, then commit the changes if any.

Then see the relevant release processes, and upload the packages to the release branch's APT suite:

Upgrade Tor Browser

See the dedicated page: tor-browser

Update PO files

Pull updated translations for languages translated in Transifex, refresh the code PO files, and commit the result, including new PO files:

./import-translations  && \
./refresh-translations && \
./submodules/jenkins-tools/slaves/check_po && \
git add po && git commit -m 'Update PO files.'

If check_po complains:

  • delete the offending PO files;
  • send a note to so that they get in touch with whoever can fix them.

When preparing an actual release

If we're about to prepare an image for a final (non-RC) release, then follow these instructions:

Major release

Merge each APT overlay suite listed in the testing branch's config/APT_overlays.d/ into the testing APT suite.


For point-releases, we generally do not put any RC out, so freeze time is the same as preparing the actual release. Hence, the following steps have already been done above, and this section is a noop in the general case.

Merge each APT overlay suite listed in the stable branch's config/APT_overlays.d/ into the stable APT suite.

Update other base branches

  1. Merge the release branch into devel following the instructions for merging base branches.

  2. Push the modified branches to Git:

     git push origin "${RELEASE_BRANCH}:${RELEASE_BRANCH}" devel:devel

Update more included files


Remove the placeholder entry for next release in debian/changelog, and then:

git checkout "$RELEASE_BRANCH" && \

This populates the Changelog with the Git log entries.

Then, launch an editor for the needed cleanup of the result:

dch -e

Then, gather other useful information from:

  • every custom bundled package's own Changelog (Greeter, Persistent Volume Assistant, etc.);
  • the diff between the previous version's .packages file and the one from the to-be-released ISO;
  • the "Fix committed" section on the Release Manager View for $VERSION in Redmine.

Finally, sanity check the version and commit:

if [ "$(dpkg-parsechangelog -SVersion)" = "${VERSION}" ]; then
    git commit debian/changelog -m "Update changelog for $VERSION."
    echo 'Error: version mismatch: please compare $VERSION with the last entry in debian/changelog'

Included website

Merge master

Merge master into the branch used for the release:

git fetch origin && git merge origin/master

version number

If preparing a RC, skip this part.

In the branch used to build the release, update the wiki/src/inc/* files to match the version number and date of the new release. Set the date at least 24 hours in the future! Between tests and mirror synchronization, the build will not be released on the same day. Try to make sure it matches the date of the future signature.


echo "$VERSION"      > wiki/src/inc/stable_i386_version.html
echo -n "$RELEASE_DATE" > wiki/src/inc/stable_i386_date.html
sed -ri "s%news/version_.*]]%news/version_$VERSION]]%" wiki/src/inc/stable_i386_release_notes.*
$EDITOR wiki/src/inc/*.html
git commit wiki/src/inc/ -m "Update version and date for $VERSION."

features and design documentation

Read the Changelog carefully, and update features pages accordingly.


git grep PENDING wiki/src/contribute/design*

... and remove the PENDING-FOR-N.M warnings.

Website translations

Refresh the website PO files and commit the ones corresponding to pages that were added or changed accordingly to changes coming with the new release. This e.g. ensures that the RC call for translation points translators to up-to-date PO files:

./build-website && git add wiki/src && git commit -m 'Update website PO files.'

Call for translation

If at freeze time, send a call for translations to tails-l10n, making it clear what Git branch the translations must be based on, and what are the priorities. Also, add a few words to remember the translation teams using Git that they should regularly contact Transifex translators, as detailed on the documentation for translators.

To get a list of changes on the website:

git diff --stat 1.1.. -- *.{mdwn,html}

Import the signing key

Skip this part if you have a Tails signing subkey on an OpenPGPG smartcard, i.e. if you are one of the usual release managers. This is only relevant when the master key has been reassembled, e.g. for signing a Tails emergency release where none of the usual release managers are available.

You should never import the Tails signing key into your own keyring, and a good practice is to import it to a tmpfs to limit the risks that the private key material is written to disk:

export GNUPGHOME=$(mktemp -d)
sudo mount -t ramfs ramfs "$GNUPGHOME"
sudo chown $(id -u):$(id -g) "$GNUPGHOME"
sudo chmod 0700 "$GNUPGHOME"
gpg --homedir $HOME/.gnupg --export $TAILS_SIGNATURE_KEY | gpg --import
gpg --import path/to/private-key

Let's also ensure that strong digest algorithms are used for our signatures, like the defaults we set in Tails:

cp config/chroot_local-includes/etc/skel/.gnupg/gpg.conf "$GNUPGHOME"

Tag the release in Git

git tag -u "$TAILS_SIGNATURE_KEY" \
  -m "tagging version ${VERSION}" "${TAG}" && \
git push --tags origin "${RELEASE_BRANCH}"

(Pushing the tag is needed so that the APT repository is updated, and the Tails APT configuration works at build and boot time. It might be premature, as testing might reveal critical issues, but this is a signed tag, so it can be overridden later. Yes, there is room for improvement here.)

Prepare the versioned APT suite

Follow the post-tag APT repository documentation.

Build images

Sanity check

Verify that the TBB release used in Tails still is the most recent. Also look if there's a new -buildX tag for the targetted TBB and Tor Browser versions in their respective Git repos:

A new tag may indicate that a new TBB release is imminent.

Better catch this before people spend time doing manual tests.

Build the almost-final image

  • Check out the release tag:

    git checkout "${TAG}"
  • Build images and carefully read the build logs to make sure nothing bad happened.

  • Check out the release branch again:

    git checkout "${RELEASE_BRANCH}"

SquashFS file order

  1. Build an ISO image.
  2. Burn a DVD.
  3. Boot this DVD on bare metal.
  4. Add profile to the kernel command-line.
  5. Login.
  6. Wait for the "Tor is ready" notification.
  7. Start the web browser.
  8. A few minutes later, once the boot-profile process has been killed, retrieve the new sort file from /var/log/boot-profile.
  9. Copy the new sort file to config/binary_rootfs/squashfs.sort.
  10. Cleanup a bit:
    • remove var/log/live/config.pipe: otherwise the boot is broken or super-slow
    • remove the bits about kill-boot-profile at the end: they're only useful when profiling the boot
  11. Inspect the Git diff (including diff stat), apply common sense. The following command is also helpful but requires that you save a copy of the old sort file into /tmp/squashfs.sort.old:

    diff -NaurB \
        <( cut -d' ' -f1 /tmp/squashfs.sort.old | sort ) \
        <( cut -d' ' -f1 config/binary_rootfs/squashfs.sort | sort ) \
        | less
  12. git commit -m 'Updating SquashFS sort file' config/binary_rootfs/squashfs.sort

Build the final image

Then all included files should be up-to-date and the versioned APT suite should be ready, so it is time to:

  • tag the release again, with all included files in:

        git tag -f -u "$TAILS_SIGNATURE_KEY" \
      -m "tagging version ${VERSION}" "${TAG}" && \
        git push origin "${RELEASE_BRANCH}" && \
        git push --tags --force
  • check out the release tag:

    git checkout "${TAG}"
  • build the final image!

  • check out the release branch again:

    git checkout "${RELEASE_BRANCH}"

Generate the OpenPGP signatures and Torrents

First, create a directory with a suitable name and go there:

mkdir "$ISOS/tails-i386-$VERSION" && \
cd "$ISOS/tails-i386-$VERSION"

Second, move the built image to this brand new directory:

mv "$ARTIFACTS/tails-i386-$VERSION.iso" \

Third, generate detached OpenPGP signatures for the image to be published, in the same directory as the image and with a .sig extension; e.g.

gpg --armor --default-key "$TAILS_SIGNATURE_KEY" --detach-sign *.iso
rename 's,\.asc$,.sig,' *.asc

Fourth, go up to the parent directory, create a .torrent file and check the generated .torrent files metainfo:

cd .. && \
mktorrent \
  -a 'udp://' \
  -a 'udp://'   \
  "tails-i386-${VERSION}" && \
btshowmetainfo tails-i386-$VERSION.torrent

Lastly, let's set some variables to be used later:

ISO_SHA256SUM="$(sha256sum "${ISO_PATH}" | cut -f 1 -d ' ' | tr -d '\n')"
ISO_SIZE_IN_BYTES="$(stat -c %s "${ISO_PATH}")"

Prepare incremental upgrades

Build the Incremental Upgrade Kits

Use tails-create-iuk to build the following IUKs:

  • From the previous stable release, e.g. 1.0 to 1.0.1 or 1.0 to 1.0.1~rc1. This may be skipped if the delta is too big (like when migrating to a new Debian release) or if there are changes outside of the scope for IUKs (like partition table changes).

  • From the last RC for the version being released, e.g. 1.0~rc1 to 1.0. This should be done even if there was no IUK generated from the previous stable release since it is a good way to test the iuk code that'll be used for the incremental upgrade paths to the next version.

Example (for RC, replace $PREVIOUS_VERSION with e.g. $VERSION~rc1 below):

sudo su -c "cd $IUK_CHECKOUT && \
    ./bin/tails-create-iuk \
       --squashfs-diff-name \"$VERSION.squashfs\"           \
       --old-iso \"$ISOS/tails-i386-$PREVIOUS_VERSION/tails-i386-$PREVIOUS_VERSION.iso\" \
       --new-iso \"$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso\"          \
       --outfile \"$ISOS/Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk\""

Note that developer tools for creating IUK and upgrade-description files were only tested on Debian sid. It should hopefully work well on Wheezy too.

Prepare upgrade-description files

  1. Prepare upgrade-description files (see the upgrade-description files specification for details). The idea is to:

    • update (create if needed) an upgrade-description file for every previous supported release (e.g. N~rc1, N-1, N-1~rc2) that replaces all existing upgrade paths with the path to the version being released;
    • create a new upgrade-description for the version being released, that expresses that no upgrade is available for that one yet.

    This is what tails-iuk-generate-ugrade-description-files tool does:

    ( cd $IUK_CHECKOUT && \
    ./bin/tails-iuk-generate-upgrade-description-files \
        --version "$VERSION" \
        --next-version "$NEXT_MAJOR_VERSION" \
        --next-version "${NEXT_MAJOR_VERSION}~rc1" \
        --next-version "${VERSION}.1" \
        --next-version "${VERSION}.1~rc1" \
        --iso "$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso" \
        --previous-version "$PREVIOUS_VERSION" \
        --previous-version "${VERSION}~rc1" \
        --iuks "$ISOS" \
        --release-checkout "$RELEASE_CHECKOUT" \
        --major-release "$MAJOR_RELEASE" \
    • The --iuks argument must point to the directory where the IUKs generated at the previous step are stored.
    • At least the last stable release and the previous release candidates for the version being released must be passed to --previous-version.
    • Older versions for which there is no incremental upgrade path to the new release must be passed with --previous-version, so that users who skipped a release or two are informed of the new one. Note that multi-steps incremental upgrade paths are valid and supported: e.g. when releasing 1.1.2, 1.1 users should still be able to incrementally upgrade to 1.1.1, and in turn to 1.1.2; to make this work, one must not pass --previous-version 1.1, that would remove the existing incremental upgrade path from 1.1 to 1.1.1.
    • If preparing a release candidate, add --channel alpha
    • If preparing a release candidate, drop all --next-version arguments, and instead pass (untested!) --next-version $(echo $VERSION | sed -e 's,~rc*$,,')
    • If preparing a point-release, pass neither --next-version "${VERSION}.1", nor --next-version "${VERSION}.1~rc1"
  2. Create an armoured detached signature for each created or modified upgrade-description file.

    find "$RELEASE_CHECKOUT/wiki/src/upgrade/" \
       -type f -name upgrades.yml -exec \
          gpg -u "$TAILS_SIGNATURE_KEY" --armor --detach-sign {} \;
  3. Rename each detached signature to .pgp:

    find "$RELEASE_CHECKOUT/wiki/src/upgrade/" -type f \
       -name upgrades.yml.asc -exec rename -f 's,\.asc$,.pgp,' {} \;
  4. Add and commit the upgrade-description files and their detached signatures to the Git branch used to prepare the release (stable or testing):

    ( cd "$RELEASE_CHECKOUT" && git add wiki/src/upgrade && \
       git commit -m "Update upgrade-description files." )
  5. Check the syntactic correctness of all upgrade-description files:

    ( cd $IUK_CHECKOUT && \
       ./bin/tails-iuk-check-upgrade-description-file \
          ${RELEASE_CHECKOUT}/wiki/src/upgrade/v1/*/*/*/*/upgrades.yml )
  6. If preparing a release candidate, move the generated or updated files to $MASTER_CHECKOUT, commit and push: given the updates are advertised on the alpha channel, while all users use the stable one by default, this will allow you to more easily test the IUK without impacting anyone.

Prepare the ISO description file for DAVE

If preparing a RC, skip this part.

Update the ISO description file (IDF) used by the browser extension:

cat > "$RELEASE_CHECKOUT"/wiki/src/install/v1/Tails/i386/stable/latest.yml <<EOF
build-target: i386
channel: stable
product-name: Tails
version: '${VERSION}'
- sha256: ${ISO_SHA256SUM}
  size: ${ISO_SIZE_IN_BYTES}
( cd "${RELEASE_CHECKOUT}" && \
  git add wiki/src/install/v1/Tails/i386/stable/latest.yml && \
  git commit -m "Update IDF file for DAVE." )

Upload images

Sanity check

Verify once more that the TBB we ship is still the most recent (see above).

Announce, seed and test the Torrents

Announce and seed the Torrents.

Test them with a BitTorrent client running in a different place.

Download and seed image from lizard

scp "$ISOS/tails-i386-$VERSION.torrent" \
   bittorrent.lizard: && \
   ssh bittorrent.lizard \
     transmission-remote --add tails-i386-$VERSION.torrent \
       --find /var/lib/transmission-daemon/downloads/

Publish the ISO and IUK over HTTP

Upload the images to the primary rsync mirror. Best practice is to first let bittorrent.lizard download the image, and then copy it from there to rsync.lizard:

ssh \
    scp -3 -r \
        bittorrent.lizard:/var/lib/transmission-daemon/downloads/tails-i386-$VERSION \
# set DIST to either 'alpha' (for RC:s) or 'stable' (for actual releases)
ssh rsync.lizard << EOF
  chown -R root:rsync_tails \
     tails-i386-$VERSION \
     Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk && \
  chmod -R u=rwX,go=rX \
     tails-i386-$VERSION \
     Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk && \
  sudo mv tails-i386-$VERSION \
          /srv/rsync/tails/tails/$DIST/ && \
  sudo mv Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk \

Update the time in project/trace file on the primary rsync mirror and on the live wiki (even for a release candidate):

TRACE_TIME=$(date +%s) &&
echo $TRACE_TIME | ssh rsync.lizard "cat > /srv/rsync/tails/tails/project/trace" && \
[ -n "$MASTER_CHECKOUT" ] && \
echo $TRACE_TIME > "$MASTER_CHECKOUT/wiki/src/inc/trace" &&
   cd "$MASTER_CHECKOUT" && \
   git commit wiki/src/inc/trace \
      -m "Updating trace file after uploading $VERSION." && \
   git push origin master

Wait for the HTTP mirrors to catch up

Wait for the next rsync pull.

Test downloading the ISO and IUK over HTTP.

Make sure every webserver listed in the round robin pool has the new version. Drop those that are lagging behind and notify their administrators:

./check-mirrors.rb --allow-multiple --fast tails-i386-$VERSION

ISO history

Push the released ISO to our Tails ISO history git-annex repo, so that our isotesters can fetch it from there for their testing. How to do so is described in our internal Git repo.

Update the website and Git repository

What follows in this section happens on the release branch in $RELEASE_CHECKOUT.

If preparing a final release

Skip this part if preparing a RC.

In order to get any new documentation into the website, merge either stable or testing (depending on which release you just did) into master.

Rename the .packages file to remove the .iso and build date parts of its name:

mv "$ARTIFACTS"/tails-i386-"$VERSION".iso.packages \

Copy the .iso.sig, .packages and .torrent files into the website repository:

cp "$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso.sig" \
   "$ARTIFACTS/tails-i386-$VERSION.packages" \
   "$ISOS/tails-i386-$VERSION.torrent" \

Remove from wiki/src/torrents/files/ any remaining file from the previous release (including any RC).

Update the size of the ISO image in inc/*:

    LC_NUMERIC=C ls -l -h $ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso | \
      cut -f 5 -d ' ' | sed -r 's/(.+)([MG])/\1 \2iB/' \
      > "$RELEASE_CHECKOUT/wiki/src/inc/stable_i386_iso_size.html"

Generate the expected signature verification output:

  gpg --keyid-format 0xlong --verify "${ISO_PATH}.sig" "${ISO_PATH}" 2>&1 | \
  sed 's/ /\&nbsp;/g;s/</\&lt;/;s/>/\&gt;/;s/$/<br\/>/g' > \

Update the known issues page:

  • Add regressions brought by the new release.
  • Remove older known issues that are fixed by the new release.

Write the announcement for the release in wiki/src/news/version_$TAG.mdwn, including:

  • 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.
  • Document important config changes that persistence users have to do themselves (e.g. the Pidgin proxy settings change in 9925321 breaks all existing persistent profiles).
  • Document known issues.

Write an announcement listing the security bugs affecting the previous version in wiki/src/security/Numerous_security_holes_in_${PREVIOUS_VERSION}.mdwn in order to let the users of the old versions know that they have to upgrade. Date it a few days before the ISO image to be released was built. Including:

If preparing a release candidate

Skip this part if preparing a final release.

Copy the .iso.sig file into the website repository:

cp "${ISO_PATH}.sig" \
   "$ISOS/tails-i386-${VERSION}.torrent" \

Write the announcement for the release in $MASTER_CHECKOUT/wiki/src/news/test_$TAG.mdwn, including:

  • Update the meta title directive.
  • Update the meta date directive.
  • Document important config changes that persistence users have to do themselves (e.g. the Pidgin proxy settings change in 9925321 breaks all existing persistent profiles).
  • Document known issues.

In any case

Generate PO files for the announcements with ./build-website.

Then, send them to so that they get translated shortly, perhaps even soon enough to integrate them before pushing the release out officially.

Then, record the last commit before putting the release out for real:

git add wiki/src && \
git commit -m "releasing version ${VERSION}"


  1. Email to ask them to test the tentative ISO.
  2. Set up a Gobby document and copy the manual test suite in it.
  3. Email to and potential contributors (see manual_testers.mdwn in the internal Git repository) that tests may start:
    • make it clear what's the deadline
    • make it clear where and how you expect to get feedback
    • attach the Torrent
    • attach the .packages file
  4. Make sure someone is committed to run the automated test suite.
  5. Make sure that enough people are here to run the tests, that they report their results in due time, and that they make it clear when they're leaving for good.
  6. Fill the holes and make sure that the manual test suite is done in due time.
  7. Triage test results, reproduce bugs as needed, decide what the next step is and make sure it happens: add to known issues? file ticket? release blocker?

Go wild!

Sanity check

Verify once more that the TBB we ship is still the most recent (see above).



If preparing a release candidate, just push the master branch:

git push origin master:master

If preparing an actual release, push the last commits to our Git repository like this:

  git push origin "$RELEASE_BRANCH:$RELEASE_BRANCH" \
                  devel:devel \
) && \
( cd "$MASTER_CHECKOUT" && \
  git fetch && \
  git merge "$RELEASE_BRANCH" && \
  git push origin master:master \

Bug tracker

Skip this part if preparing a release candidate.

Mark all issues fixed in this release as Status: Resolved in our bug tracker. For a list of candidates, see:

Then, mark the just-released Redmine milestone as done: go to the target version page, click Edit, and set Status to Closed.

Tickets linked from the website

Go through the tickets linked from the documentation and support sections of the website and point documentation writers to the tickets that might be resolved in this release.

find wiki/src/{doc,support} -name "*.mdwn" -o -name "*.html" | xargs cat | \
    ruby -e 'puts\[\[!tails_ticket\s+(\d+)[^\]]*\]\]/)' | \
    while read ticket; do
        url_content=$(curl --fail --silent ${url})
        if [ "${?}" -ne 0 ]; then
            echo "Failed to fetch ${url} so manually investigate #${ticket}" >&2
        status=$(echo "${url_content}" | \
            sed -n 's,^.*<th class="status">Status:</th><td class="status">\([^<]\+\)</td>.*$,\1,p')
        if [ "${status}" != "New" ] && \
           [ "${status}" != "Confirmed" ] && \
           [ "${status}" != "In Progress" ]; then
            echo "It seems ticket #${ticket} has been fixed (Status: ${status}) so please find all instances in the wiki and fix them. Ticket URL: ${url}"

Remember that ticket expressions, e.g. <a href="">#1234</a>, can span several lines, so finding the ones reported by the above code might be harder than git grep "tails_ticket 1234".

Test suite

Remove indications of known broken tests that were fixed by this release:

git grep XXX -- features


Update the topic in our chatroom.


Announce the release by tweeting a link to the "news" page.

Tor blog

We announce major releases on the Tor blog:

  • login to their Drupal
  • Add a New Blog Post
  • add the same tags as the previous release announce had
  • choose Filtered HTML as the Input format
  • paste the HTML generated by ikiwiki from the announce in news/ into the textarea in the blog post editor
  • cleanup a bit to make it shorter
  • add a link to the installation assistant
  • change the internal links into external links
  • turn <h1> into <strong>
  • direct users to our communication channels for comments and feedback
  • disable comments

Tor weekly news

Write a short announcement for the Tor weekly news's next issue (follow the Next steps link), or find someone who's happy to do it.

Amnesia news

The release announcement are automatically sent to amnesia-news@ (thanks to the announce flag) on an hourly basis, but it will be stuck in the moderation queue. Log in and accept it.

Prepare for the next release

XXX: adapt / fork for release candidates. In the meantime, read all this, and skip what does not make sense for a RC.

  1. If you just released a new stable release, remove the previous stable release on the mirrors.
  2. Remove any remaining RC for the just-published release from the mirrors.
  3. Remove IUKs that are more than 6 months old from /{stable,alpha}/iuk on the rsync server:

    • first check that it's not going to remove anything we want to keep:

      ssh rsync.lizard /bin/sh -c \
          \"find /srv/rsync/tails/tails/alpha  \
                 /srv/rsync/tails/tails/stable \
                 -type f -name '*.iuk' -mtime '+183' \
                 -not -name '*~test_*~test.iuk' -ls \
    • then actually delete the files:

      ssh rsync.lizard /bin/sh -c \
          \"find /srv/rsync/tails/tails/alpha  \
                 /srv/rsync/tails/tails/stable \
                 -type f -name '*.iuk' -mtime '+183' \
                 -not -name '*~test_*~test.iuk' -delete \
  4. Delete Git branches that were merged:

     bare_repo=$(mktemp -d)
     (cd "$MASTER_CHECKOUT" && git fetch) && \
     (cd "$MASTER_CHECKOUT" && git submodule update) && \
     git clone --bare --reference "$MASTER_CHECKOUT" \ \
        "$bare_repo" && \
     PYTHONPATH=lib/python3 ./bin/delete-merged-git-branches \
        --repo "$bare_repo" && \
     rm -rf "$bare_repo"
  5. Remove all old versions in wiki/src/upgrade/v1/Tails that were never released. Explanation: the post-release APT repository steps from the previous stable release will usually have had us prepare for an emergency release that was never made.

  6. Pull master back and merge it into stable, and in turn into devel
  7. Follow the post-release APT repository documentation. Make sure there are upgrade-description files for any new versions that were added.
  8. Push the resulting branches.
  9. Make sure Jenkins manages to build all updated major branches fine:
  10. Delete the Release Manager View for $VERSION Redmine custom query.
  11. Ensure the next few releases have their own Release Manager View.
  12. On the roadmap, update the Due date for the Holes in the Roof so that this section appears after the next release.
  13. If you will be the release manager for the next release, look at the tasks that must be done at the beginning of your shift in the release manager role page.

Related pages