Release 0.26.1
Information about the release
Relevant series
This should be considered the oldstable series even though we did not bump the oldstable branch as we did for the stable branch to Heptapod 0.27.
We won't perform a full shift as in for sustained support of Heptapod 0.26 in the oldstable series. Omnibus Heptapod will be the only project to have an oldstable branch for 0.26 (bare minimum for 0.26.1 release)
Main reason driving the release
GitLab 14.2.7, released after the regular EOL date of GitLab 14.2.
Task list
-
py-heptapod: no change
-
HGitaly: no change
-
Heptapod Shell: no change
-
Omnibus
-
merge stabler branches into the relevant branch if needed (no such branch) -
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): No such branches currently for 0.26 -
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: no current development branch for 0.26 -
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 (no change) -
update the requirements files in the python subdirectory if needed : no change -
if there is a new version of the hgitaly
Ruby gem, updateGemfile
and runbundle install
: no change -
commit those changes and push the topic – if there is an upstream GitLab version change, this creates a pipeline with the gitlab-prebuilds
job. Wait for its successful completion (expected time 1h). -
topic publication: create a Merge Request for the topic, select auto-merge on success (expected time 0.5h) -
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:
-
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) -
Create group milestone for next point release, move all remaining issues bearing the milestone of this release to it. -
Close milestone for this release.