### Information about the release #### Relevant series <!-- Since the introduction of the automated upstream merge process, the releasable series are `stable` and`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 feature" or "stated goals for %"some milestone" reached". ---> ### Preflight checks <!-- As of version 17.3, Heptapod Shell and py-heptapod have independent development cycles, with appropriate version bumps in the development branches of the Rails application --> - [x] make sure that HGitaly is released - [x] make sure that Heptapod Shell is released - [x] make sure that the development branch has correct `RHGITALY_SERVER_VERSION` and `HEPTAPOD_SHELL_VERSION`. ### Task list For Omnibus and the Rails application, the release branch is e.g., `heptapod-18-8` while the development branch is `heptapod`, `heptapod-stable` or `heptapod-oldstable`. - Omnibus + [x] merge stabler branches into the development branch if needed (create a MR if changes are non trivial) + [x] merge the development branch into the release branch if needed, commit without topic/push and leave as draft. + [x] if new upstream GitLab version, merge the corresponding CE tag, typically `x+y+z+ce.0` into the release branch. Leave as draft but **not in a topic**, commit and push - Rails application + [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, from `heptapod-0-20`) + [x] merge the development branch into the release branch if needed. Check `RHGITALY_SERVER_VERSION` and `HEPTAPOD_SHELL_VERSION` again. Commit. + [x] Merge new upstream GitLab version if needed. Commit. + [x] 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. + [x] set HEPTAPOD_VERSION + [x] commit the changes in version files, push the topic and create a Merge Request targeting the release branch, with automatic merge upon pipeline completion (expect about 90 minutes of running time) + [x] once the topic is published by CI, pull + [x] create a tag on the release branch head **without a topic** (run `hg topic --clear if needed` before) + [x] 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 [Omnibus pipeline](https://foss.heptapod.net/heptapod/omnibus-heptapod/-/pipelines) 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: - [ ] take note of the Docker image ID that the heptapod-tests CI jobs ran for - [ ] retrieve the image built in the Omnibus pipeline, checking the Mercurial tag and the Docker image ID, and push it to Docker Hub, using the `release-full` script of heptapod/heptapod-docker>. ### Finalisations - [x] announce the release at least on Twitter and Mastodon - [x] publish the changesets in all repositories made during the process (don't forget Omnibus) - [ ] (Final minor versions only): close group milestone for this minor version (`x.y`), moving all remaining issues to the next one.