jiva 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
developbranch, a release branch is created. Name of the release branch should follow the naming convention ofv<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 and release a new version of Jiva Operator.
Patch releases are created on demand, depending on the severity of the fixes. The fixes will have to merged into the develop branch and cherry picked into the corresponding release branches and a new patch release is created.
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
- Quay.io
- quay.io/jiva
- GHCR
- ghcr.io/jiva
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/unreleasedtochangeslogs/released/<release tag>. - Update [CHANGELOG.md] with fixes that went into the current release.