Skip to content
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

Jump to bottom

Add RELEASE.md #1216

Merged
merged 1 commit into from
May 24, 2023
Merged

Add RELEASE.md #1216

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
46 changes: 46 additions & 0 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Release Process

Kpack release process is composed of 3 phases:
- [Development](#development)
- [Feature Complete](#feature-complete)
- [Release Finalization](#release-finalization)

## Phases

### Development

Our development flow is detailed in [Development](DEVELOPMENT.md).

### Feature Complete

During this period, a **Release Candidate** (RC) is published and used for further User Acceptance testing (`UAT`). Furthermore, additional RCs may be published based on assessment by the `kpack` maintainers of the **impact**, **effort** and **risk** of including the changes in the upcoming release. Any other changes may be merged into the `main` branch through the normal process, and will make it into the next release.

To produce the release candidate a maintainer will:
- Create a new release branch in form `release/<MAYOR-VERSION>.<MINOR-VERSION>.<PATCH-VERSION>-rc.<NUMBER>` yielding a draft GitHub release to be published.
- Publish the [GitHub release][release]:
- Tag release branch as `v<MAYOR-VERSION>.<MINOR-VERSION>.<PATCH-VERSION>-rc.<NUMBER>`.
- Release should be marked as "pre-release".
- The GitHub release will contain the following:
- **artifacts**
- **release notes**
- The release notes should be edited and cleaned

### Release Finalization

The maintainer will:
- Create a new release branch in form `release/<MAYOR-VERSION>.<MINOR-VERSION>.<PATCH-VERSION>` yielding a draft GitHub release to be published.
- Publish the [GitHub release][release] while tagging the release branch as `v<VERSION>`.
- Tag release branch as `v<MAYOR-VERSION>.<MINOR-VERSION>.<PATCH-VERSION>`.
tomkennedy513 marked this conversation as resolved.
Show resolved Hide resolved
- The GitHub release will contain the following:
- **artifacts**
- **release notes**

And with that, you're done!

## Release automation

- The release candidate process is automated using [GitHub Actions][github-release]. The workflow is triggered by a push to a release branch.
- The release finalization is manual step

[release]: https://github.com/pivotal/kpack/releases
[github-release]: https://github.com/pivotal/kpack/blob/main/.github/workflows/ci.yaml