Release 0.41.0rc1

Information about the release

Relevant series

stable

Main reason driving the release

GitLab 16.3, 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.

  • merge stabler branches into the branch to release and run a pipeline to check them (fast)
  • set the version in heptapod/VERSION, commit
  • run $python setup.py sdist and push to PyPI with twine
  • tag accordingly to the pushed version
  • set a new development version in heptapod/VERSION, 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
  • 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.
  • commit
  • run $python setup.py sdist and push to PyPI with twine
  • 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
  • check that the tag pipeline passed and pushed the RHGitaly source tarball to download.h.n.

• 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 #352 (closed)

• 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.
  • Merge new upstream GitLab version if needed. Commit.
  • fill in HEPTAPOD_CHANGELOG 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 RHGITALY_SERVER_VERSION if needed
  • update the requirements files in the python subdirectory if needed. In particular, update the HGitaly version in common.req
  • 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.