Information about the release
Main reason driving the release
py-heptapod: no change
HGitaly: if there are changes to include in the relevant branch (
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
if there are changes in Mercurial-specific protocol, regenerate the
Ruby library (this sets the appropriate version) and publish the resulting
$python setup.py sdist andpush 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
Heptapod Shell: same as in GitLab 14.5
- merge stabler branches into the relevant branch if needed
if new upstream GitLab version, merge the corresponding CE tag,
x+y+z+ce.0into the relevant branch. Leave as draft but not in a topic, commit and push
The release branch is e.g.,
heptapod-0-20while the development branch is
- merge stabler development branches into the development branch (pipelines not really needed).
start a topic from the head of the release branch (e.g,
- 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 the requirements files in the python subdirectory if needed
if there is a new version of the
hgitalyRuby gem, update
- 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
- once the topic is published by CI, pull
create a tag on the release branch head without a topic (run
hg topic --clear if neededbefore)
- 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
- Docker push for those two image tags.
- 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.