### Main reason driving the release New GitLab upstream version 13.10. Sadly couldn't finish the feature flags for the fully native mode without any impact if not activated, but it's close! ### 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. + [x] merge stabler branches into the branch to release and run a pipeline to check them (fast) + [x] set the version in `setup.py`, commit + [x] run `$python setup.py sdist and `push to PyPI with [twine](https://twine.readthedocs.io/en/latest/) + [x] tag accordingly to the pushed version + [x] set a new development version in `setup.py`, commit + [x] push and publish these three changesets - HGitaly: if there are changes to include in the relevant branch (`default`, `stable` or `oldstable`). All changes in the default branch are about the fully native mode, we don't need to release them for this rc1. - 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. No new upstream version to merge. - Omnibus + [x] merge stabler branches into the relevant branch if needed + [x] 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`. + [x] merge stabler development branches into the development branch (pipelines not really needed). + [x] start a topic from the head of the release branch (e.g, `heptapod-0-20`) + [x] merge the `heptapod` branch into the release branch if needed. Commit. + [x] fill in [HEPTAPOD_CHANGELOG](HEPTAPOD_CHANGELOG.md) Be sure to include the changes related to the stable branches. If needed copy them from the stable *release* branches, as these won't get merged. + [x] set HEPTAPOD_VERSION + [x] update HEPTAPOD_SHELL_VERSION if needed + [x] update the requirements files in the [python](python) subdirectory if needed + [x] commit those changes and push the topic + [x] 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)