Feast uses semantic versioning. As such, while it is still pre-1.0 breaking changes will happen in minor versions.
Contributors are encouraged to understand our branch workflow described below, for choosing where to branch when making a change (and thus the merge base for a pull request).
Major and minor releases are cut from the
Each major and minor release has a long-lived maintenance branch, for example
v0.3-branch. This is called a "release branch".
From the release branch, pre-release release candidates are tagged ie
From the release candidates, stable patch version releases are tagged, for example
A release branch should be substantially feature complete with respect to the intended release. Code that is committed to
master may be merged or cherry-picked on to a release branch, but code that is directly committed to a release branch should be solely applicable to that release (and should not be committed back to master).
In general, unless you're committing code that only applies to a particular release stream (for example, temporary hot-fixes, back-ported security fixes, or image hashes), you should base changes from
master and then merge or cherry-pick to the release branch.
For Feast maintainers, these are the concrete steps for making a new release.
For new major or minor release, create and check out the release branch for the new stream, e.g.
v0.6-branch. For a patch version, check out the stream's release branch.
Update versions for the release/release candidate with a commit:
In the root
-SNAPSHOT from the
<revision> property, update versions, and commit.
Tag the commit with the release version, using a
for a release candidate, create tags
for a stable release
X.Y.Z create tags
Check that versions are updated with
If changes required are flagged by the version lint, make the changes, amend the commit and move the tag to the new commit.
Push the commits and tags. Make sure the CI passes.
If the CI does not pass, or if there are new patches for the release fix, repeat step 2 & 3 with release candidates until stable release is achieved.
Bump to the next patch version in the release branch, append
pom.xml and push.
Create a PR against master to:
Bump to the next major/minor version and append
Add the change log by applying the change log commit created in step 2.
Check that versions are updated with
env TARGET_MERGE_BRANCH=master make lint-versions
Update the Upgrade Guide to include the action required instructions for users to upgrade to this new release. Instructions should include a migration for each breaking change made to this release.
Update Feast Supported Versions to include the supported versions of each component.
When a tag that matches a Semantic Version string is pushed, CI will automatically build and push the relevant artifacts to their repositories or package managers (docker images, Python wheels, etc). JVM artifacts are promoted from Sonatype OSSRH to Maven Central, but it sometimes takes some time for them to be available. The
sdk/go/v tag is required to version the Go SDK go module so that users can go get a specific tagged release of the Go SDK.
We use an open source change log generator to generate change logs. The process still requires a little bit of manual effort.
Create a GitHub token as per these instructions. The token is used as an input argument (
-t) to the change log generator.
The change log generator configuration below will look for unreleased changes on a specific branch. The branch will be
master for a major/minor release, or a release branch (
v0.4-branch) for a patch release. You will need to set the branch using the
You should also set the
--future-release argument. This is the version you are releasing. The version can still be changed at a later date.
Update the arguments below and run the command to generate the change log to the console.
docker run -it --rm ferrarimarco/github-changelog-generator \--user feast-dev \--project feast \--release-branch <release-branch-to-find-changes> \--future-release <proposed-release-version> \--unreleased-only \--no-issues \--bug-labels kind/bug \--enhancement-labels kind/feature \--breaking-labels compat/breaking \-t <your-github-token> \--max-issues 1 \-o
Review each change log item.
Make sure that sentences are grammatically correct and well formatted (although we will try to enforce this at the PR review stage).
Make sure that each item is categorised correctly. You will see the following categories:
Fixed bugs, and
Merged pull requests. Any unlabelled PRs will be found in
Merged pull requests. It's important to make sure that any
bug fixes are pulled up out of
merged pull requests into the correct category. Housekeeping, tech debt clearing, infra changes, or refactoring do not count as
enhancements. Only enhancements a user benefits from should be listed in that category.
Make sure that the "Full Change log" link is actually comparing the correct tags (normally your released version against the previously version).
Make sure that release notes and breaking changes are present.
It's important to flag breaking changes and deprecation to the API for each release so that we can maintain API compatibility.
Developers should have flagged PRs with breaking changes with the
compat/breaking label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label
compat/breaking to PRs with undeclared breaking changes. The change log will have to be regenerated if any new labels have to be added.