Skip to content

Latest commit

 

History

History
83 lines (63 loc) · 3.32 KB

RELEASE.md

File metadata and controls

83 lines (63 loc) · 3.32 KB

Release Process for OLM v1

Choosing version increment

The operator-controller following Semantic Versioning guarantees:

  • Major: API breaking change(s) are made.
  • Minor: Backwards compatible features are added.
  • Patch: Backwards compatible bug fix is made.

When a Major or Minor release being made is associated with one or more milestones, please ensure that all related features have been merged into the main branch before continuing.

Creating the release

Note that throughout this guide, the upstream remote refers to the operator-framework/operator-controller repository. The release process differs slightly based on whether a patch or major/minor release is being made.

Patch Release

In this example, we will be creating a new patch release from version v1.2.3 on the branch release-v1.2.

Step 1

First, make sure the release-v1.2 branch is updated with the latest changes from upstream:

git fetch upstream release-v1.2
git checkout release-v1.2
git reset --hard upstream/release-v1.2

Step 2

Run the following command to confirm that your local branch has the latest expected commit:

git log --oneline -n 5

Check that the most recent commit matches the latest commit in the upstream release-v1.2 branch.

Step 3

Create a new tag, incrementing the patch number from the previous version. In this case, we'll be incrementing from v1.2.3 to v1.2.4:

## Previous version was v1.2.3, so we bump the patch number up by one
git tag v1.2.4
git push upstream v1.2.4

Major/Minor Release

Step 1

Create a release branch from main branch for the target release. Follow the pattern release-<MAJOR>.<MINOR> when naming the branch; for example: release-v1.2. The patch version should not be included in the branch name in order to facilitate an easier patch process.

git checkout main
git fetch upstream main
git pull main
git checkout -b release-v1.2
git push upstream release-v1.2

Step 2

Create and push our tag for the current release.

git tag v1.2.0
git push upstream v1.2.0

Post-Steps

Once the tag has been pushed the release action should run automatically. You can view the progress here. When finished, the release should then be available on the releases page.

Backporting Policy

Significant security and critical bug fixes can be backported to the most recent minor release. Special backport requests can be discussed during the weekly Community meeting or via Slack channel; this does not guarantee an exceptional backport will be created.

Occasionally non-critical issue fixes will be backported, either at an approver’s discretion or by request as noted above. If you believe an issue should be backported, please feel free to reach out and raise your concerns or needs. For information on contacting maintainers via the #olm-dev Slack channel and attending meetings. To know more about see How to Contribute.

Process

  1. Create a PR with the fix cherry-picked into the release branch
  2. Ask for a review from the maintainers.
  3. Once approved, merge the PR and perform the Patch Release steps above.