Release Heptapod 0.21.0rc1
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!
py-heptapod: 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
$python setup.py sdist andpush to PyPI with twine
- tag accordingly to the pushed version
set a new development version in
- push and publish these three changesets
HGitaly: if there are changes to include in the relevant branch (
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.
- 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,
heptapodbranch into the release branch if needed. Commit.
- fill in HEPTAPOD_CHANGELOG 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.
- set HEPTAPOD_VERSION
- update HEPTAPOD_SHELL_VERSION if needed
- update the requirements files in the python subdirectory if needed
- commit those changes and push the topic
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)
- if the upstream GitLab version is changed in the release, run a pipeline from the Web UI, with the variable
- once the topic is published, maybe 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)