Skip to content

Commit

Permalink
chore: update release procedure
Browse files Browse the repository at this point in the history
I think I was the first person to try the release procedure, and there were a few
things that were out of date or clearly copied from Podman Desktop.

- There is no label kind/release (and I don't think it's worth creating one).
- Simplified to 'maintainers', since it's not necessarily the same set of people.
- The release timeline was just copied from Podman Desktop and completely wrong
  this time - at least clarified that's when we're releasing at the same time.
- Improved ordering of / simplified closing the release vs issues in it.
- Version bump PR is not auto-merged, changed the wording.
- Clarified it's the catalog that actually makes the release visible.
- Moved checking the published image to the correct place in the workflow
  (before we test it).
- Simplified/reorganized/reformatted the testing and publishing sections.
- Minor wording improvements.

Related to containers#1842.

Signed-off-by: Tim deBoer <[email protected]>
  • Loading branch information
deboer-tim committed Oct 17, 2024
1 parent 644f98c commit 0a42e65
Showing 1 changed file with 21 additions and 29 deletions.
50 changes: 21 additions & 29 deletions RELEASE.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,15 @@

## Pre-requisites

- Create Enhancement Issue `Release vX.X.X` for current sprint, then update the label to `kind/release` and assign it to yourself.
- Confirm with Podman Desktop maintainers that pending / need-to-go-in PR's have been merged.
- Create Enhancement Issue `Release vX.X.X` for the current sprint, and assign it to yourself.
- Confirm with maintainers that pending / need-to-go-in PR's have been merged.
- Notify main contributors on Discord / Slack.

In the below example, we will pretend that we're upgrading from `1.1.0` to `1.2.0`. Please use the CORRECT release numbers as these are just example numbers.

## Release timeline

Below is what a typical release week may look like:
When AI Lab is released at the same time as Podman Desktop, this is what a typical release week may look like:

- **Monday (Notify):** 48-hour notification. Communicate to maintainers and public channels a release will be cut on Wednesday and to merge any pending PRs. Inform QE team. Start work on blog post as it is usually the longest part of the release process.
- **Tuesday (Staging, Testing & Blog):** Stage the release (see instructions below) to create a new cut of the release to test. Test the pre-release (master branch) build briefly. Get feedback from committers (if applicable). Push the blog post for review (as it usually takes a few back-and-forth reviews on documentation).
Expand All @@ -20,44 +20,36 @@ Below is what a typical release week may look like:

## Releasing on GitHub

1. Go to https://github.com/containers/podman-desktop-extension-ai-lab/actions/workflows/release.yaml
1. Click on the top right drop-down menu `Run workflow`
1. Go to https://github.com/containers/podman-desktop-extension-ai-lab/actions/workflows/release.yaml.
1. Click on the top right drop-down menu `Run workflow`.
1. Enter the name of the release. Example: `1.2.0` (DO NOT use the v prefix like v1.2.0)
1. Specify the branch to use for the new release. It's main for all major releases. For a bugfix release, you'll select a different branch.
1. Click on the `Run workflow` button.
1. Note: `Run workflow` takes approximately 2-3 minutes.
1. Close the milestone for the respective release, make sure that all tasks within the milestone are completed / updated before closing. https://github.com/containers/podman-desktop-extension-ai-lab/milestones
1. Make sure that all tasks for the respective release milestone are completed / updated, then close it. https://github.com/containers/podman-desktop-extension-ai-lab/milestones
1. If not already created, click on `New Milestone` and create a new milestone for the NEXT release.
1. Check that https://github.com/containers/podman-desktop-extension-ai-lab/actions/workflows/release.yaml has been completed.
1. There should be an automated PR that has been created. This will be automatically merged in after all tests have been ran (takes 5-10 minutes). The title looks like `chore: 📢 Bump version to 1.3.0`. Rerun workflow manually if some of e2e tests are failing.
1. Above PR MUST be merged before continuing with the steps.
1. Edit the new release https://github.com/containers/podman-desktop-extension-ai-lab/releases/edit/v1.2.0
1. Select previous tag (v1.1.0) and click on `Generate release notes` and the click on `Update release`
1. Ensure the image has been successfully published to https://github.com/containers/podman-desktop-extension-ai-lab/pkgs/container/podman-desktop-extension-ai-lab.
1. There should be an automated PR that has been created. The title looks like `chore: 📢 Bump version to 1.3.0`. Rerun workflow manually if some of e2e tests are failing.
1. Wait for the PR above to be approved and merged before continuing with the steps.
1. Edit the new release https://github.com/containers/podman-desktop-extension-ai-lab/releases/edit/v1.2.0.
1. Select previous tag (v1.1.0) and click on `Generate release notes` and then click on `Update release`.

## Test release before it is rolling out.
## Release testing

The release is a pre-release, it means it is not yet the latest version, so no clients will automatically update to this version.
At this stage the release is not in the catalog, so clients will not automatically update to this version.

It allows QE (and everyone else) to test the release before they it will go live on the catalog.
This allows QE (and everyone else) to test the release before it goes live.

❌ All severe bugs and regressions are investigated and discussed. If we agree any should block the release, we need to fix the bugs and do a respin of the release with a new .z release like 1.2.1 instead of 1.2.0.

## Next phase
- Create a branch if it does not exist. For example 1.2.1 if 1.2.0 failed. Then, cherry-pick bugfixes into that branch.

- ❌ All severe bugs and regressions are investigated and discussed. If we agree any should block the release, need to fix the bugs and do a respin of the release with a new .z release like 1.2.1 instead of 1.2.0.

Create a branch if it does not exist. For example 1.2.x if 1.2.0 failed. Then, cherry-pick bugfixes in that branch.

- ✅ If committers agree we have a green light, proceed. **Do not forget to change the release from 'pre-release' to 'latest release' before proceeding**.

## Updating catalog

Pre-requisites:

- Ensure the release is OK (green workflow, image has been published https://github.com/containers/podman-desktop-extension-ai-lab/releases https://github.com/containers/podman-desktop-extension-ai-lab/pkgs/container/podman-desktop-extension-ai-lab).

#### Catalog

Create and submit a PR to the catalog (https://github.com/containers/podman-desktop-catalog on branch gh-pages). This is manual and will be automated in the future.
✅ If committers agree we have a green light, proceed.

## Publishing and updating the catalog

All steps above must be complete and successful before proceeding, including verifying the published images, testing, and green light!

1. Change the release in GitHub from 'pre-release' to 'latest release'.
1. Create and submit a PR to the catalog (https://github.com/containers/podman-desktop-catalog on branch gh-pages). This is manual and will be automated in the future.

0 comments on commit 0a42e65

Please sign in to comment.