Release Heptapod 0.20.4
Main reason driving the release
- Security release GitLab 13.9.5
- a few fixes of our own
Task list
-
py-heptapod: if there are changes to include in the relevant branch (
default
,stable
oroldstable
).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
setup.py
, commit -
run
$python setup.py sdist and
push to PyPI with twine - tag accordingly to the pushed version
-
set a new development version in
setup.py
, commit - push and publish these three changesets
-
HGitaly: if there are changes to include in the relevant branch (
default
,stable
oroldstable
).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
setup.py
, 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
setup.py
, commit - push and publish these three changesets
-
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.
(not needed for this release)
-
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 isheptapod
,heptapod-stable
orheptapod-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
heptapod
branch 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 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:
- 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
octobus/heptapod:x.y.z
andoctobus/heptapod:latest
- Docker push for those two image tags.
Finalisations
- announce the release at least on Twitter and Mastodon
- publish the changesets in all repositories made during the process (don't forget Omnibus)