Release process
Release process
For Feast maintainers, these are the concrete steps for making a new release.
1. (for patch releases) Cherry-pick changes into the branch from master
If you were cutting Feast 0.22.3, for example, you might do:
git checkout v0.22-branch (or git pull upstream v0.22-branch --rebase if you've cut a release before)
git cherry-pick [COMMIT FROM MASTER]
Note: if you're handling a maintenance release (i.e. an older version), semantic release may complain at you. See to enable an older branch to cut releases.
After this step, you will have all the changes you need in the branch.
2. Pre-release verification
A lot of things can go wrong. One of the most common is getting the wheels to build correctly (and not accidentally building dev wheels from improper tagging or local code changes during the release process). Another possible failure is that the Docker images might not build correctly.
We verify the building the wheels and Docker images in your fork of Feast, not the main feast-dev/feast repo.
For minor releases (e.g. v0.22.0)
Merge upstream master changes into your fork. Make sure you are running the workflow off of your fork!
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
For patch releases (e.g. v0.22.3)
You should already have checked out the existing minor release branch from step 1 (e.g. v0.22-branch).
Push the minor release branch to your fork (git push -u origin <branch>).
Add a patch release tag (e.g v0.22.1) by running git tag <tag>.
This is important. If you don't have a tag, then the wheels you build will be dev wheels
3. Release for Python and Java SDK
Generate a or retrieve your saved personal access token.
The personal access token should have all of the permissions under the repo checkbox.
4. (for minor releases) Post-release steps
4a: Creating a new branch
Create a new branch based on master (i.e. v0.22-branch) and push to the main Feast repo. This will be where cherry-picks go for future patch releases and where documentation will point.
4b: Adding a high level summary in the GitHub release notes
By default, Semantic Release will pull in messages from commits (features vs fixes, etc). But this is hard to digest, so it helps to have a high level overview. See https://github.com/feast-dev/feast/releases for the releases.
4c: Update documentation
In the Feast Gitbook (ask in Slack for access):
Create a new space within the Feast collection
Go to the overflow menu on the top -> Synchronize with Git
Specify GitHub as the provider
