For Feast maintainers, these are the concrete steps for making a new release.
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 --rebaseif you've cut a release before)
git cherry-pick [COMMIT FROM MASTER]
git push upstream v0.22-branchto commit changes to the release branch
Note: if you're handling a maintenance release (i.e. an older version), semantic release may complain at you. See Sample PR to enable an older branch to cut releases.
After this step, you will have all the changes you need in the branch.
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.
- 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.
This is important. If you don't have a tag, then the wheels you build will be dev wheels, which we can't push. The release process will automatically produce a tag for you via Semantic Release.
- Checkout master branch and run
git tag v0.22.0.
git push --tagsto push the tag to your forks master branch.
- 3.Access the
Actionstab on your GitHub UI on your fork and click the
build_wheelsaction. This workflow will build the python sdk wheels for Python 3.8-3.10 on MacOS 10.15 and Linux and verify that these wheels are correct. It will also build the Docker images. The publish workflow uses this action to publish the python wheels for a new release to PyPI.
- 4.Look for the header
This workflow has a workflow_dispatch event triggerand click
Run Workflowon the right.
- 5.Run the workflow off of the tag you just created(
v0.22.0in this case, not the master branch) and verify that the workflow worked (i.e ensure that all jobs are green).
You should already have checked out the existing minor release branch from step 1 (e.g.
- 1.Push the minor release branch to your fork (
git push -u origin <branch>).
- 2.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, which we can't push. The release process will automatically produce a tag for you via Semantic Release.
- 3.Push tags to your origin branch (not the upstream feast-dev/feast branch) with
git push origin <tag>.
- 4.Kick off
build_wheelsworkflow in your fork in the same way as is detailed in the last section, running the workflow from this tag you just pushed up.
- 1.Generate a Personal Access Token or retrieve your saved personal access token.
- The personal access token should have all of the permissions under the
- 2.Access the
Actionstab on the main
feast-dev/feastrepo and find the
- 3.Look for the header
This workflow has a workflow_dispatch event triggeragain and click
Run Workflowon the right.
- If you are making a minor or major release, you should run it off of the master branch.
- If you are making a patch release, run it off of the corresponding minor release branch.
- 4.Try the dry run first with your personal access token. If this succeeds, uncheck
Dry Runand run the release workflow.
- 5.Then try running normally (without dry run).
- First, the
releaseworkflow will kick off. This publishes an NPM package for the Web UI (NPM package), bumps files versions (e.g. helm chart, UI, Java pom.xml files), and generate a changelog using Semantic Release. All jobs should succeed.
- Second, the
publishworkflow will kick off. This builds all the Python wheels (PyPI link, publishes helm charts, publishes the Python and Java feature servers to Docker (DockerHub images), publishes the Java Serving Client + Datatypes libraries to Maven (Maven repo)
- 6.Try to install the Feast Python release in your local environment and test out the
feast applyworkflow to verify as a sanity check that the release worked correctly.
- 7.Verify the releases all show the new version:
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.
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.
- 1.Create a new space within the Feast collection
- 2.Go to the overflow menu on the top -> Synchronize with Git
- 1.Specify GitHub as the provider
- 2.Configure to point to the new release branch
- 3.Publish the new page for this branch as part of the collection
- 4.Go back to the main Feast collection and go to the overflow menu -> "Customize collection"
- 5.Configure the default space to be your new branch and save
- 6.Verify on docs.feast.dev that this new space is the default (this may take a few minutes to propagate, and your browser cache may be caching the old branch as the default)