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

Update release docs #249

Merged
merged 1 commit into from
Oct 11, 2024
+12 −8
Merged

Update release docs #249

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
20 changes: 12 additions & 8 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,14 @@
# Release

A release of chronicle comprises:
- a new semver git tag from the current tip of the main branch
- a new [github release](https://github.com/anchore/chronicle/releases) with a changelog and archived binary assets

Ideally releasing should be done often with small increments when possible. Unless a
breaking change is blocking the release, or no fixes/features have been merged, a good
target release cadence is between every 1 or 2 weeks.


## Creating a release

This release process itself should be as automated as possible, and has only a few steps:
Expand All @@ -9,23 +18,18 @@ This release process itself should be as automated as possible, and has only a f
you can abort and adjust the labels on the PRs and issues to be included in the release and
re-run the release trigger command.

1. A release admin must approve the release on the GitHub Actions release pipeline run page.
1. A release admin must approve the release on the GitHub Actions [release pipeline](https://github.com/anchore/chronicle/actions/workflows/release.yaml) run page.
Once approved, the release pipeline will generate all assets and publish a GitHub Release.

1. If there is a release Milestone, close it.

Ideally releasing should be done often with small increments when possible. Unless a
breaking change is blocking the release, or no fixes/features have been merged, a good
target release cadence is between every 1 or 2 weeks.


## Retracting a release

If a release is found to be problematic, it can be retracted with the following steps:

- Delete the GitHub Release
- Deleting the GitHub Release
- Add a new `retract` entry in the go.mod for the versioned release

**Note**: do not delete release tags from the git repository since there may already be references to the release
in the go proxy, which will cause confusion when trying to reuse the tag later (the H1 hash will not match and there
will be a warning when users try to pull the new release).

Loading