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.

Sign up for GitHub

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

Operator-Controller Release Guide #149

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
44b7df5
Operator-Controller Release Guide
dtfranz Mar 30, 2023
10c8255
Small fixes
dtfranz Mar 30, 2023
21bbb93
Remove 'z' from release branch naming, use makefile env for olm v0 pr…
dtfranz Mar 31, 2023
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
View file
Open in desktop
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/v0.24.0/install.sh | bash -s v0.24.0
Copy link
Member

Choose a reason for hiding this comment

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

Should we make the OLM version an environment variable that comes in from the Makefile?

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we make the OLM version an environment variable that comes in from the Makefile?

I think that's a good idea if we plan to depend on OLMv0 long term

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
8 changes: 6 additions & 2 deletions README.md
View file
Open in desktop
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
55 changes: 55 additions & 0 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# 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.z`.
Copy link
Member

@joelanford joelanford Mar 31, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

WDYT about naming this branch simply release-v1.2?

Copy link
Contributor

Choose a reason for hiding this comment

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

WDYT about naming this branch simply release-v1.2?

I actually like that better than including the z at the end :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

SGTM! 😊

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.z
git pull release-v1.2.z
git checkout release-v1.2.z
```
#### 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>.z` when naming the branch; for example: `release-v1.2.z`. The final character should be `z` to facilitate future patch releases.
```bash
git checkout main
git fetch upstream main
git pull main
git checkout -b release-v1.2.z
git push upstream release-v1.2.z
```

#### 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).