# Shipwright Release Process

This documents the process for issuing a new _feature release_.
Feature releases increment the minor version number of Shipwright components.

## Before release

- Check for open issues assigned to a milestone. Determine if any should be considered "release blockers" or moved to the next milestone.
- Review outstanding pull requests for items to be merged into the release.
- Review dependencies in `go.mod` that should be updated prior to release. Create a GitHub issue if these updates should block release.
- Announce intent to release - at a Community meeting, Slack, and/or on the shipwright-dev mailing list.
- Ensure a release blog post issue is created and assigned.
- Check the sample build strategies for any deprecated/removed APIs. Update these as needed.

## Step 1.1: Create Release Branch for Build repo

A maintainer for shipwright-io/build should run the "Create Release Branch" GitHub Action workflow.
The following parameters should be provided:

- The major + minor semantic version of the release. Ex: for v0.13.0, the version should be v0.13
- The git reference to branch from. Leave this as `main` unless there is a compelling reason to reference a particular commit SHA.

## Step 1.2: create a release candidate build of the Build repo

Go to the [Release action](https://github.com/shipwright-io/build/actions/workflows/release.yaml) and run the worklow (requires permission). Branch is `release-v{version}`, previous tag is the last release, desired tag is the new one.
Desired tag must be a valid semantic version (format vX.Y.Z), and release candidates should have a `-rc<N>` extension. Example: v0.13.0-rc0 for the 0th release candidate of v0.13.0

Wait for the build to be completed.

Go to [Releases](https://github.com/shipwright-io/build/releases). There should be a draft release. Click the **Publish release** button at the bottom. This will give us the tag in the repository and a pre-release.

Review and update the generated release note section whether pull requests are correctly listed.

## Step 2.1 Update the CLI

In the CLI, run `go get github.com/shipwright-io/build@NEW_TAG` to update the dependencies in the go.mod. If necessary, fix compilation issues. Also update other references in `Makefile`, and `hack/install-shipwright.sh`. Open a PR with your changes, get it approved and released.

## Step 2.2 Update the Operator

1. Download the `release.yaml` from the build repo release, and save it in `kodata/release.yaml`
2. Check for any RBAC changes in `release.yaml`, and apply any build controller RBAC permission updates to the `config/rbac/shipwright_build_controller.yaml`
3. Update the `VERSION` default in the Makefile to the next released version.
4. Submit a pull request to update the operator.

## Step 2.3 Prepare the update of the documentation on the website

TODO

Open a PR but do not merge it.

## Step 3.1: Create Release Branch for CLI repo

A maintainer for shipwright-io/cli should run the "Create Release Branch" GitHub Action workflow.
The following parameters should be provided:

- The major + minor semantic version of the release. Ex: for v0.13.0, the version should be v0.13
- The git reference to branch from. Leave this as `main` unless there is a compelling reason to reference a particular commit SHA.

## Step 3.2 Release the CLI

Go to the [Release action](https://github.com/shipwright-io/cli/actions/workflows/release.yml) and run the worklow (requires permission). Branch is release-vX.Y, previous tag is the last release, desired tag is the new one.

Once the action completed, go to the [releases](https://github.com/shipwright-io/cli/releases) and edit the new release. Check **This is a pre-release**, click **Update Release**.

Review and update the generated release note section whether pull requests are correctly listed.

## Step 3.2 Release the Operator

1. (admin) Run the "Release" GitHub action with the following parameters
* "Desired Tag" - the semantic version of the next release _without a leading v_. (this is a bug that should be fixed)
* "Previous Tag" - the previous release's tag in GitHub. This is a semantic version with a leading "v"
2. Review and update the generated release note in GitHub.
3. Add a leading "v" to the proposed tag for the release. This is a bug that should be fixed.

## Step 4 Publish the Operator to OperatorHub

1. Ensure that you are listed as a reviewer in our operator's `ci.yaml` [file](https://github.com/k8s-operatorhub/community-operators/blob/main/operators/shipwright-operator/ci.yaml). If you are not a reviewer, please submit a separate PR to add yourself to the reviewers list.
2. Check out the [k8s community operators repo](https://github.com/k8s-operatorhub/community-operators), ensure that your main branch is up to date.
3. Create a new local branch for the update.
4. Add a subdirectory under `operators/shipwright-operator` with the semantic version of the update (no leading "v").
5. Extract the contents of the released operator-bundle image. This can be accomplished with podman:

   $ podman image mount ghcr.io/shipwright-io/operator/operator-bundle:<release-tag> | cp
   $ cp -r manifests /path/to/k8s-operatorhub/community-operators/operators/shipwright-operator/<release-version>/
   $ cp -r metadata ~/yaml/github.com/k8s-operatorhub/community-operators/operators/shipwright-operator/0.10.0/
   $ cp -r tests ~/yaml/github.com/k8s-operatorhub/community-operators/operators/shipwright-operator/0.10.0/

6. Verify the contents of the operator cluster service version in `manifests/shipwright-operator.clusterserviceversion.yaml`. In particular, verify the SHAs of any referenced image. If necessary, update the references to use correct image tags/shas.
7. Commit your changes with a signed commit, and submit a pull request to the k8s community operators repo with the new version.

## Step 5 Create website pull request with the blog post and the release notes

Similar as previous PRs, for example https://github.com/shipwright-io/website/pull/73/files Don't forget to update the index.html page.

Open a PR but do not merge it.

## Step 6 Publish everything

- Publish the GitHub pre-releases
- Merge the README update in the build repo
- Merge the website pull requests.

## Step 7 Advertise on Twitter

- Add a tweet for the new release pointing to the blog post for more details
- Unpin the old release tweet
- Pin the new release tweet

## Step 8 Advertise on the mailing list

## Step 9 Advertise on Slack