Release 0.31.0
Information about the release
Relevant series
default
Main reason driving the release
EOL of GitLab 14.8 (Heptapod 0.30)
Task list
-
py-heptapod: no change
-
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 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 as1.2.4dev0
(no dot for proper interpretation by the Rails app); commit -
push and publish these three changesets
-
-
Heptapod Shell: no change
-
Omnibus: no change
-
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 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 hgitaly
Ruby gem, updateGemfile
and runbundle 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:
-
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.