Skip to content

Latest commit

 

History

History
35 lines (26 loc) · 1.98 KB

RELEASE.md

File metadata and controls

35 lines (26 loc) · 1.98 KB
Raw

Release Process

jiva-operator follows the OpenEBS release process for major and minor releases. The scope of the release is determined by contributor availability. The scope is published in the Release Tracker Projects. The release process involves the following steps:

  • After all the scoped features are committed to develop branch, a release branch is created. Name of the release branch should follow the naming convention of v<major-release>.<minor-release>.x. Example: v1.9.x.
  • Create release candidate (RC) tags from the release branch and run release pipelines.
  • Create release tag once the verification is complete.
  • Update the changelog.
  • Update yaml and helm charts.
  • Update Documentation in this repository as well as openebs/website and openebs/openebs.
  • Announce the release via community channels.

Patch releases are created on demand, depending on the severity of the fixes. The fixes will have to merged into the main branch and cherry picked into the corresponding release branches and a new patch release is created.

Released Containers Images

Multi-arch containers are pushed to different container registeries, via the Github Actions release workflow.

The following container images are generated from this repo:

  • Docker Hub (Default)
    • openebs/jiva-operator
    • openebs/jiva-csi
  • Quay.io
    • quay.io/jiva-operator
    • quay.io/jiva-csi
  • GHCR
    • ghcr.io/jiva-operator
    • ghcr.io/jiva-csi

Update CHANGELOG

Once a release tag is created, raise a changelog PR to develop branch that updates the following:

  • Move the fixes that went into the release from changeslogs/unreleased to changeslogs/released/<release tag>.
  • Update [CHANGELOG.md] with fixes that went into the current release.