Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 161
    • Issues 161
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • heptapod
  • heptapodheptapod
  • Issues
  • #558

Closed
Open
Created Oct 25, 2021 by Georges Racinet@gracinet🦑Owner32 of 35 tasks completed32/35 tasks

Release Heptapod 0.26.0rc1

Information about the release

Relevant series

default

Main reason driving the release

New features

Task list

  • py-heptapod: if there are changes to include in the relevant branch (default, stable or oldstable).

    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 heptapod/VERSION, commit
    • run $python setup.py sdist and push to PyPI with twine
    • tag accordingly to the pushed version
    • set a new development version in heptapod/VERSION, commit
    • push and publish these three changesets
  • HGitaly: if there are changes to include in the relevant branch (default, stable or oldstable).

    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, 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 as 1.2.4dev0 (no dot for proper interpretation by the Rails app); 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.

    • merge stabler branches into the branch to release and run a pipeline to check them (fast)
    • tag and push, following the convention stated in #352 (closed)
  • 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 is heptapod, heptapod-stable or heptapod-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.
    • 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
    • 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 and octobus/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.
Edited Oct 29, 2021 by Georges Racinet
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking