API, Supported Versions & Deprecation

Tracking Feast's API Compatibility, support Feast versions, Deprecation.

Overview

This document tracks Feast's API compatibility. Users are dependent on Feast providing a stable, compatible API such that Feast upgrades do not significantly impact the systems that they have built on Feast, while developers have to make changes to correct API design decisions that no longer make sense. By tracking Feast's API Compatibility, support Feast versions, this document attempts to find common ground between the two needs.

1. Release Versioning

Feast follows semantic versioning to version its components in the form MAJOR.MINOR.PATCH. Different Feast Components are versioned together (ie Core, Serving, SDKs).

  • Stable releases are versioned MAJOR.MINOR.PATCH

  • Pre-release releases are versioned as MAJOR.MINOR.PATCH-SNAPSHOT or MAJOR.MINOR.PATCH-rc.NUMBER for release candidates.

While Feast is still pre-1.0 breaking changes will happen in minor versions.

2. API Compatibility

Defining API

Feast defines API as anything that is directly user facing, accessible by the user directly. This includes:

  • SDKs' user facing methods/classes.

  • Protobufs used in Feast messaging.

  • gRPC/HTTP Service APIs.

  • Database schemas.

  • Configuration Files.

Breaking Changes

Defining Breaking Changes:

  • Adding something that users need to use for existing functionality (eg. adding a required parameter).

  • Changing how a given API should be interpreted.

  • Changing a default value in parameter in the API.

  • Removing something from the API.

Introducing Breaking Changes

What steps should developers take when proposing breaking changes.

  • Propose a deprecation by making a Pull Request and updating the Deprecation section in this document.

  • Flag deprecated APIs with deprecated in code and in release notes in the Pull Request.

Once deprecation period has expired the developer may introduce the breaking change:

  • Flag Breaking changes in release notes with breaking and action required.

  • Ensure that detailed upgrade instructions are provided in the release notes for users to follow when upgrading.

3. Supported Versions

Support Table

Support Table defines which versions of Feast components are currently supported:

Component

Supported Versions

Feast Core

0.7

Feast Serving

0.7

Feast Go SDK

0.6, 0.7

Feast Python SDK/CLI

0.6, 0.7

Feast Java SDK

0.6, 0.7

Patch Releases

Patch Releases typically contain critical backwards compatible bug fixes. Users should ensure that they are running the latest patch release of the selected minor version of Feast.

Component Skew

Feast's toleration for Component Skew is as follows:

  • Feast Core, Serving, Job Coordinator are compatible with the same patch version.

  • Feast Core/Serving/Job Coordinator are backwards compatible with Feast SDKs for one minor version. (ie Feast 0.6 is compatible with Feast 0.5 SDKs).

4. Deprecations

Tracks deprecation in Feast APIs, expiry release and mitigation and migration.

A breaking change or removal can be made to a deprecated API when it reaches its expiry release. Users are encouraged to migrate their systems before the expiry release.

Deprecation

Breaking Change Release

Components Affected

Mitigation/Migration

Specifying project in FeatureReferences when retrieving from Serving via GetOnlineFeatures is no longer supported.

0.8

Serving's Service API

  • SDK users: Migrate to a SDK with version >= 0.6

  • API users: Use specialized project field in GetOnlineFeaturesRequest when retrieving via GetOnlineFeatures.

  • get_batch_features will be changed to get_historical_features

  • get_online_features entity_rows field will only take in a list of dictionaries instead ofGetOnlineFeaturesRequest.EntityRow

0.8

Python SDK

  • Python SDK users: Migrate to a SDK with version >= 0.7