### Information about the release #### Relevant series stable #### Main reason driving the release [GitLab 16.3](#1188), which is a landmark version for migrations ### 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 `heptapod/VERSION`, 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 `heptapod/VERSION`, commit + [x] 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. + [x] merge stabler branches into the branch to release and run a pipeline to check them (fast) + [x] set the version in `hgitaly/VERSION` + [x] if there are changes in Mercurial-specific protocol, regenerate the Ruby library (this sets the appropriate version) and publish the resulting gem. See `ruby/README.md` for details. + [x] 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 (`hg tag 1.2.3`) + [x] set a new development version in `hgitaly/VERSION`, such as `1.2.4dev0` (no dot for proper interpretation by the Rails app); commit + [x] push and publish these three changesets + [ ] check that the tag pipeline passed and pushed the RHGitaly source tarball to [download.h.n](https://download.heptapod.net/rhgitaly). - 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. + [x] merge stabler branches into the branch to release and run a pipeline to check them (fast) + [x] tag and push, following the convention stated in heptapod#352 - 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 development branch into the release branch if needed. 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](HEPTAPOD_VERSION) + [x] update [HEPTAPOD_SHELL_VERSION](HEPTAPOD_SHELL_VERSION) if needed + [x] update [RHGITALY_SERVER_VERSION](RHGITALY_SERVER_VERSION) if needed + [x] update the requirements files in the [python](python) subdirectory if needed. In particular, update the HGitaly version in [common.req](python/common.req) + [x] if there is a new version of the `hgitaly` Ruby gem, update `Gemfile` and run `bundle install` + [ ] review and commit the changes, push the topic and create a Merge Request targeting the release branch, with automatic merge upon pipeline completion (estimated time between 40 and 90 minutes depending on whether there is a GitLab upstream update) + [ ] In case of GitLab upstream update, check that the pipeline contains the `gitlab-prebuilds` job. + [ ] once the topic is published by CI, 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: - [ ] 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 utility in heptapod/heptapod-docker>. Example: ``` ~/heptapod/docker $ ./registry-pull-heptapod-push-docker \ --push \ --verify-hg-tag heptapod-0.32.1-1 \ --expected-image-id sha256:0e976fdfa6733d4298025cd0b98ae36384863c8dd8d60ac7f9f979bb5d05b259 ``` - [ ] retag the image as as `octobus/heptapod:x.y.z` and `octobus/heptapod:latest` or `octobus/heptapod:x-y-latest`, and push the tags to Docker Hub, using the `push-release` script from heptapod/heptapod-docker>. ### Finalisations - [ ] announce the release at least on Twitter and Mastodon - [ ] publish the changesets in all repositories made during the process (don't forget Omnibus) - [ ] Create group milestone for next point release, move all remaining issues bearing the milestone of this release to it. - [ ] Close milestone for this release.