Skip to content
Merged
Changes from 1 commit
Commits
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
Prev Previous commit
Next Next commit
Fix
Signed-off-by: Kevin Zhang <kzhang@tecton.ai>
  • Loading branch information
kevjumba committed Jul 1, 2022
commit 256bc63635c2b4a97ca50d29e4fe3111f787b715
10 changes: 8 additions & 2 deletions docs/project/release-process.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,7 @@

For Feast maintainers, these are the concrete steps for making a new release.

### Pre-release Verification (Verification that wheels are built correctly)

### Pre-release Verification (Verification that wheels are built correctly) for minor release.
1. Merge upstream master changes into your **fork**. Make sure you are running the workflow off of your fork!
2. Create a tag manually for the release on your fork. For example, if you are doing a release for version 0.22.0, create a tag by doing the following.
- Checkout master branch and run `git tag v0.22.0`.
Expand All @@ -14,6 +13,13 @@ For Feast maintainers, these are the concrete steps for making a new release.
4. Look for the header `This workflow has a workflow_dispatch event trigger` and click `Run Workflow` on the right.
5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of verification?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clarified.


### Pre-release Verification (Verification that wheels are built correctly) for patch release.
1. Check out the branch of your release (e.g `v0.22-branch` on your local fork) and push this to your fork.
2. Cherry pick commits that are relevant to the patch release onto your forked branch.
3. Add a patch release tag (e.g `v0.22.1`) by running `git tag <tag>`.
4. Push tags to origin branch with `git push origin <tag>`.
5. Kick off `build_wheels` workflow in the same way as is detailed in the last section off of the patch release tag.

### Release
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What stuff does this workflow do? Python release? Java release? UI release? Helm charts? Docker images?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarified

1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token.
- The personal access token should have all of the permissions under the `repo` checkbox.
Expand Down