Skip to content

Operator-Controller Release Guide #149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 31, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .goreleaser.yml
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,7 @@ release:
## Installation

```bash
curl -L -s https://github.com/operator-framework/operator-lifecycle-manager/releases/download/{{ .Env.OLM_V0_VERSION }}/install.sh | bash -s {{ .Env.OLM_V0_VERSION }}
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/{{ .Env.CERT_MGR_VERSION }}/cert-manager.yaml
kubectl wait --for=condition=Available --namespace=cert-manager deployment/cert-manager-webhook --timeout=60s
kubectl apply -f https://github.com/operator-framework/rukpak/releases/latest/download/rukpak.yaml
Expand Down
1 change: 1 addition & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ export IMAGE_TAG ?= devel
export GO_BUILD_TAGS ?= upstream
export CERT_MGR_VERSION ?= v1.9.0
export GORELEASER_VERSION ?= v1.16.2
export OLM_V0_VERSION ?= v0.24.0
export WAIT_TIMEOUT ?= 60s
IMG?=$(IMAGE_REPO):$(IMAGE_TAG)

Expand Down
8 changes: 6 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,12 @@
# operator-controller
// TODO(user): Add simple overview of use/purpose
The operator-controller is the central component of Operator Lifecycle Manager (OLM) v1. It extends Kubernetes with an API through which users can install Operators.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intent with these two sections in the README was not to fully flesh them out yet but mostly just to get rid of the TODOs 🙂


## Description
// TODO(user): An in-depth paragraph about your project and overview of use
OLM v1 is the follow-up to OLM v0, located [here](https://github.com/operator-framework/operator-lifecycle-manager). It consists of four different components, including this one, which are as follows:
* operator-controller
* [deppy](https://github.com/operator-framework/deppy)
* [rukpak](https://github.com/operator-framework/rukpak)
* [catalogd](https://github.com/operator-framework/catalogd)

## Getting Started
You’ll need a Kubernetes cluster to run against. You can use [KIND](https://sigs.k8s.io/kind) to get a local cluster for testing, or run against a remote cluster.
Expand Down
53 changes: 53 additions & 0 deletions RELEASE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Release Process for OLM v1

## Choosing version increment
When making releases for operator-controller, version increments should adhere strictly to Semantic Versioning. In short:
* 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
#### Step 1
In this example we will be creating a new patch release from version `v1.2.3`, on the branch `release-v1.2`.
First ensure that the release branch has been updated on remote with the changes from the patch, then perform the following:
```bash
git fetch upstream release-v1.2
git pull release-v1.2
git checkout release-v1.2
```

#### Step 2
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`:
```bash
## 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.
```bash
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.
```bash
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](https://github.com/operator-framework/operator-lifecycle-manager/actions/workflows/goreleaser.yaml). When finished, the release should then be available on the [releases page](https://github.com/operator-framework/operator-controller/releases).