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 guide with more details #651

Merged
merged 2 commits into from
Sep 14, 2024
Merged

Update release guide with more details #651

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
78c7faf
Add more to releaes guide
IanHoang Sep 13, 2024
d74fd7f
Update grammar
IanHoang Sep 13, 2024
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
18 changes: 15 additions & 3 deletions RELEASE_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Releases are tagged with labels in the scheme `vN.N.N`, for instance `v1.0.0`, `
The release process is standard across repositories in this open-source project and is run by a release manager volunteering from amongst the [maintainers](MAINTAINERS.md).

## Backport PRs
Add backport labels to PRs and commits so that changes can be added to `main` branch and other related major and minor version branches. For example, if a PR is published as a patch fix for OSB version 1.3.0, it should be labeled with a backport label called `backport-1.3` so that it backports to `1.3` branch.
Add backport labels to PRs and commits so that changes can be added to `main` branch and other related major and minor version branches. For example, if a PR is published as a patch fix for OSB version 1.3.0, it should be labeled with a backport label called `backport-1.3` so that it backports to `1.3` branch.

## Prerequisites

Expand All @@ -55,7 +55,7 @@ NOTE: The version number below is in semantic format, for instance, `1.2.0`.

1. Create a tag: `git tag <VERSION> main`
1. Ensure that this is done in the main official opensearch-benchmark repository
2. This should be the new version that matches the version in version.txt.
2. This should be the `<VERSION>` tag that matches the entry in version.txt.
3. For patch releases: Change `main` to the major and minor version branch name

2. Push the tag: `git push origin <VERSION>`
Expand Down Expand Up @@ -119,11 +119,23 @@ Send this message in the following channels in OpenSearch Community Slack:

## Error Handling

### Remove a tag

If error occurs during build process and need to retrigger the workflow, do the following:

* Delete the tag locally `git tag -d <VERSION>`
* Delete the tag locally `git tag -d <VERSION>` and `git push --delete origin <VERSION>` to remove in remote repository
* Delete the tag on Github
* Delete draft-release on Github

Then, create the tag again and push it.


### Rename a tag

If you published an incorrect tag name, then follow these steps:

1. Run `git tag new_tag_name old_tag_name` to move old tag references to new tag alias
2. Run `git tag -d old_tag_name` to delete old tag locally
3. Ensure your remote is correct with `git remote -v`. Run `git push origin :refs/tags/old_tag_name` to remove old tag references in remote repository
4. Run `git push origin --tags` to make remote tags look like local tags
5. Verify that the release draft is pointing to the new tag
Loading