* **Create Batch Features:** ELT/ETL systems like Spark and SQL are used to transform data in the batch store.

* **Feast Apply:** The user \(or CI\) publishes versioned controlled feature definitions using `feast apply`. This CLI command updates infrastructure and persists definitions in the object store registry.

* **Prediction:** A backend system makes a request for a prediction from the model serving service.

* **Get Online Features:** The model serving service makes a request to the Feast Online Serving service for online features using a Feast SDK.

A complete Feast deployment contains the following components:

Projects provide complete isolation of feature stores at the infrastructure level. This is accomplished through resource namespacing, e.g., prefixing table names with the associated project. Each project should be considered a completely separate universe of entities and features. It is not possible to retrieve features from multiple projects in a single request. We recommend having a single feature store and a single project per environment \(`dev`, `staging`, `prod`\).

{% hint style="info" %}

Projects are currently being supported for backward compatibility reasons. Projects may change in the future as we simplify the Feast API.

{% endhint %}

Our preference is the use of `git rebase` instead of `git merge` : `git pull -r`

Commits have to be signed before they are allowed to be merged into the Feast codebase:

git commit -s -m "My first commit"

* Fill in the description based on the default template configured when you first open the PR

* What this PR does/why we need it

* Feast Protobuf API specifications are written in [proto3](https://developers.google.com/protocol-buffers/docs/proto3) in the Main Feast Repository.

* Changes to the API should be proposed via a [GitHub Issue](https://github.com/feast-dev/feast/issues/new/choose) for discussion first.

The language specific bindings have to be regenerated when changes are made to the Feast Protobuf API:

| [Main Feast Repository](https://github.com/feast-dev/feast) | Golang | Run `make compile-protos-go` to generate bindings |

| [Feast Java](https://github.com/feast-dev/feast-java) | Java | No action required: bindings are generated automatically during compilation. |

1. Create a GitHub token as [per these instructions](https://github.com/github-changelog-generator/github-changelog-generator#github-token). The token is used as an input argument \(`-t`\) to the change log generator.

2. 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 `--release-branch` argument.

It's important to flag breaking changes and deprecation to the API for each release so that we can maintain API compatibility.

Feast uses [semantic versioning](https://semver.org/).

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.

Application status indicators for Feast:

* API reference documentation

* Deprecative changes must span multiple minor versions and allow for an upgrade path.

Feast components have various levels of support based on the component status.

| Beta | The Feast community offers best-effort support for beta applications. Beta applications will be supported for at least 2 more minor releases. |

| Alpha | The response differs per application in alpha status, depending on the size of the community for that application and the current level of active development of the application. |

Feast has an active and helpful community of users and contributors.

Since Feast 0.10, it is not necessary to deploy Feast into Kubernetes any more. Feast runs as a light weight CLI/SDK that can configure your managed services to operate as a feature store. The documentation contained within this section exists for posterity sake and relates to Feast 0.9, which depends on both Kubernetes and Spark. Teams that want to consume from streaming sources have to continue to use this release until streaming support has been reintroduced to Feast.

{% endhint %}