### Information about the release

#### Relevant series

<!--

Either `default`, `stable` or `oldstable`.

-->

#### Main reason driving the release

<!---

It can be interesting to state what was important enough to trigger
the release.

One does not need to repeat the changelog, just a few
words, can be wording such as "new upstream GitLab version"
or "first version with xx featrure" or "stated goals for %"some milestone"
reached".
--->

### Task list

- py-heptapod: if there are changes to include in the relevant branch
  (`default`, `stable` or `oldstable`).

  Don't forget changesets from stabler branches.

  + [ ] merge stabler branches into the branch to release and run a pipeline
    to check them (fast)
  + [ ] set the version in  `setup.py`, commit
  + [ ] run `$python setup.py sdist and `push to PyPI with
        [twine](https://twine.readthedocs.io/en/latest/)
  + [ ] tag accordingly to the pushed version
  + [ ] set a new development version in `setup.py`, commit
  + [ ] push and publish these three changesets

- HGitaly: if there are changes to include in the relevant branch
  (`default`, `stable` or `oldstable`).

  Don't forget changesets from stabler branches.

  + [ ] merge stabler branches into the branch to release and run a pipeline
    to check them (fast)
  + [ ] set the version in  `hgitaly/VERSION`, commit
  + [ ] run `$python setup.py sdist and `push to PyPI with
        [twine](https://twine.readthedocs.io/en/latest/)
  + [ ] tag accordingly to the pushed version (`hg tag 1.2.3`)
  + [ ] set a new development version in `hgitaly/VERSION`,
        such as `1.2.4dev0` (no dot for proper interpretation by the
        Rails app);
        commit
  + [ ] push and publish these three changesets

- Heptapod Shell: again, if needed which is more than likely of
  Heptapod x.y.0 and not so common for further versions of the x.y series.

  + [ ] merge stabler branches into the branch to release and run a pipeline
    to check them (fast)
  + [ ] tag and push, following the convention stated in heptapod#352

- Omnibus

  + [ ] merge stabler branches into the relevant branch if needed
  + [ ] if new upstream GitLab version, merge the corresponding CE tag,
    typically `x+y+z+ce.0` into the relevant branch. Leave as draft but **not
    in a topic**, commit and push

- Rails application

  The release branch is e.g., `heptapod-0-20` while the development branch
  is `heptapod`, `heptapod-stable` or `heptapod-oldstable`.

  + [ ] merge stabler development branches into the development branch
    (pipelines not really needed).
  + [ ] start a topic from the head of the release branch (e.g, `heptapod-0-20`)
  + [ ] merge the development branch into the release branch if needed. Commit.
  + [ ] fill in [HEPTAPOD_CHANGELOG](HEPTAPOD_CHANGELOG.md)
    Be sure to include the changes related to the stabler branches. If needed
    copy them from the stabler *release* branches, as these won't get merged.
  + [ ] set HEPTAPOD_VERSION
  + [ ] update HEPTAPOD_SHELL_VERSION if needed
  + [ ] update the requirements files in the [python](python) subdirectory
    if needed
  + [ ] commit those changes and push the topic
  + [ ] pipelines. There are two cases
    - if the upstream GitLab version is changed in the release, run a
      pipeline from the Web UI, with the variable
      `UPDATE_GITLAB_PREBUILDS=yes`. Publish the topic once it passes
      (expected time 1h).
    - if the upstream GitLab version stays unchanged, create a Merge Request
      for the topic, select auto-merge on success (expected time 0.5h)
  + [ ] once the topic is published, maybe pull
  + [ ] create a tag on the release branch head **without a topic** (run
    `hg topic --clear if needed` before)
  + [ ] push the tag, don't publish it yet. The tag pipeline will push the
    source tarball to download.h.n and push a commit to reference it and
    a tag in Omnibus. The resulting pipeline in Omnibus will build the
    package for Ubuntu, then the Docker image, then trigger a full run
    of the functional tests on it, as a pipeline on heptapod-tests.
  + Docker image:
    - [ ] double check that the heptapod-tests CI jobs did run for
      the image built in the Omnibus pipeline.
    - [ ] retrieve the image built by the Omnibus pipeline from registry.h.n,
      retag it as `octobus/heptapod:x.y.z` and `octobus/heptapod:latest`
    - [ ] Docker push for those two image tags.

### Finalisations

- [ ] announce the release at least on Twitter and Mastodon
- [ ] publish the changesets in all repositories made during the process (don't
  forget Omnibus)
