Merge remote-tracking branch 'flapflap/de-network_configuration'

[tails-test.git] / wiki / src / contribute / release_process.mdwn

[[!meta title="Release process"]]

[[!toc levels=2]]

See the [[release_schedule]].

Environment
===========

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

* version numbers:

      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`).
* `TAILS_SIGNATURE_KEY=0D24B36AA9A2A651787876451202821CBE2CD9C1`
* `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.

Pre-freeze
==========

The [[contribute/working_together/roles/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`

Coordinate with Debian security updates
---------------------------------------

See [[release_process/Debian_security_updates]].

Select the right branch
=======================

For a major release, the `devel` branch should be merged into the `testing`
branch and changes should be made from there.

From minor releases, work should happen in `stable`.

<div class="caution">
Then, read this document from the branch used to prepare the release.
</div>

Update included files
=====================

AdBlock patterns
----------------

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

1. Boot Tails
2. Start the tor Browser and open *Tools* → *Addons*
3. Select *Adblock Plus* in extensions
4. Open *Preferences* → *Filter preferences…*
5. For each filters, click *Actions* → *Update 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.' \
          config/chroot_local-includes/etc/tor-browser/profile/adblockplus/patterns.ini

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
        ../tails/import-translations

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

Add and commit.

Then check the PO files:

        ./wiki/src/contribute/l10n_tricks/check_po.sh

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

Then see the relevant release processes:

* [[liveusb-creator]]
* [[tails-greeter]]
* [[perl5lib]]
* [[persistence-setup]]
* [[tails-iuk]]
* whisperback:
  * follow [upstream release process](https://git-tails.immerda.ch/whisperback/plain/HACKING)
  * build a Debian package
  * upload it to our [[APT repository]]

Upgrade the Tor Browser
-----------------------

See the dedicated page: [[tor-browser]]

Update PO files
---------------

Pull updated translations for languages translated in Transifex:

        ./import-translations

Refresh the code PO files:

        ./refresh-translations

Commit the result, including new PO files:

        git add po && git commit -m 'Update PO files.'

Freeze
------

If we are at freeze time for a major release:

* Merge the `master` Git branch into `devel`.
* Merge the `devel` Git branch into `testing`.
* Reset the `testing` APT suite to the state of the `devel` one, as
  documented on [[contribute/APT_repository#workflow-freeze]].
* If there is no Jenkins job building ISO images from the `testing`
  branch, ask <tails-sysadmins@boum.org> to re-activate it.

Else, if we are at freeze time for a point-release:

* Merge the `master` Git branch into `stable`.

Changelog
---------

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

        ./release $VERSION $PREVIOUS_VERSION

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 "Fix committed" section on the *Release Manager View*
  in Redmine.

Finally, commit:

        git commit debian/changelog -m "Update changelog for $VERSION."

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.

        RELEASE_DATE='June 26, 2013'

        echo "$VERSION"      > wiki/src/inc/stable_i386_version.html
        echo "$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
        ./build-wiki
        git commit wiki/src/inc/ -m "Update version and date for $VERSION."

### features and design documentation

Read the Changelog carefully, and update [[doc/about/features]]
pages accordingly.

Also:

        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-wiki && 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|contribute/how/translate]].

To get a list of changes on the website:

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

Import the signing key
======================

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 tmpfs tmpfs "$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

(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|contribute/APT_repository#workflow-post-tag]] APT
repository documentation.

Build images
============

Build the almost-final image
----------------------------

[[Build images|contribute/build]] and carefully read the build logs to
make sure nothing bad happened.

SquashFS file order
-------------------

1. Build an ISO image.
1. Burn a DVD.
1. Boot this DVD **on bare metal**.
1. Add `profile` to the kernel command-line.
1. Login.
1. Wait for the "Tor is ready" notification.
1. Start the web browser.
1. A few minutes later, once the `boot-profile` process has been
   killed, retrieve the new sort file from `/var/log/boot-profile`.
1. Copy the new sort file to `config/binary_rootfs/squashfs.sort`.
1. 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
1. 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

1. `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 push --tags`
*  build the final image!

<a id="prepare-iuk"></a>

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, copy the built image to this brand new directory.
Then, rename it:

        mv "$ARTIFACTS/tails-i386-*-$VERSION-*.iso" "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 'http://torrent.gresille.org/announce' "tails-i386-${VERSION}" && \
        btshowmetainfo tails-i386-$VERSION.torrent

Fifth, generate detached OpenPGP signatures for every published
`.torrent` file:

        gpg --armor --default-key "$TAILS_SIGNATURE_KEY" --detach-sign \
          tails-i386-$VERSION.torrent && \
        mv tails-i386-$VERSION.torrent.{asc,sig}

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 && \
      PERL5LIB=\"$PERL5LIB_CHECKOUT/lib\" \
        ./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.

<a id="prepare-upgrade-description-files"></a>

Prepare upgrade-description files
---------------------------------

1. Prepare upgrade-description files (see the [[upgrade-description
   files
   specification|contribute/design/incremental_upgrades#upgrade-description-files]]
   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" \
       )

   Note:
   * 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"`

1. 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 {} \;

1. Rename each detached signature to `.pgp`:

       find "$RELEASE_CHECKOUT/wiki/src/upgrade/" -type f \
          -name upgrades.yml.asc -exec rename -f 's,\.asc$,.pgp,' {} \;

1. 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." )

1. 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 )

1. 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.

Upload 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:

* <https://gitweb.torproject.org/builders/tor-browser-bundle.git>
* <https://gitweb.torproject.org/tor-browser.git>

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

Better catch this before people spend time doing manual tests.

## 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

Publish the ISO 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 lizard.tails.boum.org \
        scp -3 -r \
            bittorrent.lizard:/var/lib/transmission-daemon/downloads/tails-i386-$VERSION \
            rsync.lizard:
    # 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
      chmod -R u=rwX,go=rX tails-i386-$VERSION
      sudo mv tails-i386-$VERSION /srv/rsync/tails/tails/$DIST/
    EOF

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."
        )

<a id="publish-iuk"></a>

Publish the IUKs
----------------

Same as for the ISO, but the IUKs should land into
`/srv/rsync/tails/tails/$DIST/iuk/`.

Wait for the HTTP mirrors to catch up
-------------------------------------

Wait for the next rsync pull.

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

Test downloading the ISO and IUK over HTTP.

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 \
           "$ARTIFACTS/tails-i386-$VERSION.packages"

Copy the `.iso.sig`, `.packages`, `.torrent` and `.torrent.sig` 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" \
           "$ISOS/tails-i386-$VERSION.torrent.sig" \
           "$RELEASE_CHECKOUT/wiki/src/torrents/files/"

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

Generate the SHA-256 hash of every image
to be released in `inc/*`:

        sha256sum $ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso | \
          cut -f 1 -d ' ' | tr -d '\n' \
          > "$RELEASE_CHECKOUT/wiki/src/inc/stable_i386_hash.html"

Update the [[support/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
`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
  [[!tails_gitweb_commit 9925321]] breaks all existing persistent
  profiles).
- Document known issues.
- Update the link(s) to these release notes in
  `wiki/src/doc/first_steps/upgrade.mdwn`.

Write an announcement listing the security bugs affecting the previous
version in `security/` 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:

- the list of CVE fixed in Linux since the one shipped in the previous
  release of Tails:
  <http://ftp-master.metadata.debian.org/changelogs/main/l/linux/unstable_changelog>
- the list of DSA fixed in packages we ship since those that were in
  the previous release of Tails: <http://security.debian.org/>
- the list of BSA fixed in packages we ship since those that were in
  the previous release of Tails:
  <https://lists.debian.org/debian-backports-announce/>
- the list of MFSA fixed by the Tor Browser update:
  <https://www.mozilla.org/security/announce/>

If preparing a release candidate
--------------------------------

Skip this part if preparing a final release.

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

        cp "$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso.sig" \
           "$MASTER_CHECKOUT/wiki/src/torrents/files/"

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
  [[!tails_gitweb_commit 9925321]] breaks all existing persistent
  profiles).
- Document known issues.

In any case
-----------

Generate PO files for the announcements with `./build-wiki`.

Then, send them to <tails-l10n@boum.org> 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}"

Testing
=======

1. Set up a Gobby document and copy the [[manual test
   suite|contribute/release_process/test]] in it.
1. Email to <tails@boum.org> and potential contributors 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
1. Email <tails-testers@boum.org> to ask them to test the tentative ISO.
1. Make sure someone is committed to run the automated test suite.
1. 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.

Go wild!
========

Sanity check
------------

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

Push
----

### Git

Push the last commits to our Git repository:

        ( cd "$RELEASE_CHECKOUT" && git push ) && \
        ( cd "$MASTER_CHECKOUT" && git fetch && git merge "$RELEASE_BRANCH" && git push )

... and ask <root@boum.org> to refresh the ikiwiki wrappers for
our website.

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:

* the [issues in *Fix committed*
  status](https://labs.riseup.net/code/projects/tails/issues?query_id=111);
* the "Fix committed" section on the [Release Manager
  View](https://labs.riseup.net/code/projects/tails/issues?query_id=130).

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 ticket that might be resolved in
this release.

    git grep tails_ticket -- "wiki/src/[ds]*/*.mdwn"

Test suite
----------

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

        git grep XXX -- features

IRC
---

Update the topic in our [[chatroom|chat]].

Twitter
-------

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](https://blog.torproject.org/user)
- *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 our [[download page|download]]
- change the internal links into external links
- turn `<h1>` into `<strong>`
- direct users to [[our communication channels|support/talk]] for
  comments and feedback
- disable comments

Tor weekly news
---------------

Write a short announcement for the Tor weekly news, or find someone
who's happy to do it.

Amnesia news
------------

The release notes should have been automatically sent to
`amensia-news@` (thanks to the `announce` flag) but it will be stuck
in the moderation
queue. [Log in](https://mailman.boum.org/admindb/amnesia-news) 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. Move the previous stable release to `obsolete` on the mirrors.
1. Remove any remaining RC for the just-published release from
   the mirrors.
1. 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' \
                    -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' \
                    -delete \
             \"

1. Pull `master` back and merge it into `devel`.
1. Follow the
   [[post-release|contribute/APT_repository#workflow-post-release]] APT
   repository documentation.
1. Push the resulting `devel` branch.
1. If this was a major release, then reset experimental:
   - take note of branches merged into `experimental`, but not into
     `devel`:

         git log --pretty=oneline --color=never --merges devel..experimental \
           | /bin/grep 'into experimental$' \
           | sed -e 's,^[a-f0-9]\+\s\+,,' | sort -u

   - `git checkout experimental && git reset --hard devel`
   - [[hard reset|contribute/APT_repository#workflow-reset]] the `experimental`
     APT suite to the state of the `devel` one.
   - merge additional branches into experimental (both at the Git and
     APT levels)

         for branch in $UNMERGED_BRANCHES ; do
            git merge $branch
            suite=$(echo $branch | sed -e 's,[/_],-,g')
            if [ $(ssh reprepro@incoming.deb.tails.boum.org reprepro list $suite | wc -l) -gt 0 ] ; then
               ssh reprepro@incoming.deb.tails.boum.org tails-merge-suite $suite experimental
            fi
         done

   - `git push --force origin experimental`
1. Make sure Jenkins manages to build all updated major branches fine:
   <https://jenkins.tails.boum.org/>.
1. Delete the _Release Manager View for $VERSION_ Redmine custom query.
1. Ensure the next few releases have their own _Release Manager View_.
1. On the [[!tails_roadmap]], update the *Due date* for the *Broken
   windows* so that this section appears after the next release.
* If the next release is a point-release, ask
  <tails-sysadmins@boum.org> to disable the Jenkins job that's
  building ISO images from the `testing` branch (since it basically
  won't be used/maintained in the next 2.5 months).

Related pages
=============

[[!map pages="contribute/release_process/*"]]