René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Create API compatibility and Supported Versions Policy for Feast","articleBody":"## Background\r\nAs Feast evolves and matures over time, and new users integrate Feast into their systems, we are faced with two conflicting needs:\r\n- Developers need a way make breaking changes to add new features/rectify design decisions that no longer make sense:\r\n     - Removing versions in FeatureSets PR #676\r\n     - Adding Field Status metadata to Online Serving PR #658  \r\n     - Generalising Source model from being tied to Kafka PR #685 \r\n     - Evolving Feast's Data model #479 \r\n- Users need time to transition their systems that are built on top of Feast during which Feast should offer compatibility guarantees . Upgrades should be as painless as possible. They also need to aware about what changes they have to make to transition from one version to another. \r\n     - [Introduce changes in Evolutionally Friendly way](https://github.com/gojek/feast/pull/658#issuecomment-621381351) by @ches \r\n     - [Versioning APIs](https://github.com/gojek/feast/pull/658#issuecomment-621687755) by @zhilingc \r\n \r\nFor guidance on how to resolve this we can look at Kubernetes does it:\r\n- [Handling Version Skew in Components/Backward Compatiblity](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew)\r\n- [What constitutes a compatible change](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#on-compatibility)\r\n- [Versioning APIs to introducing backward incompatible changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#incompatible-api-changes)\r\n- [Deprecating APIs](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)\r\n\r\nUser Facing APIs in Question for context:\r\n- [Ingestion (FeatureRow) API](https://github.com/gojek/feast/blob/3d9bafd12515b872c479cfb0f7369e11eb0663d9/protos/feast/types/FeatureRow.proto#L28)\r\n- [Core API](https://github.com/gojek/feast/blob/9139fe317eea713b2d6bdb83334483be3c2188ef/protos/feast/core/CoreService.proto#L30)\r\n- [Serving API](https://github.com/gojek/feast/blob/5b69331ea5589976093a9b7bae60a135036ddaa1/protos/feast/serving/ServingService.proto#L29)\r\n- Feast Python SDK/CLI\r\n- Feast Java SDK\r\n- Feast Golang SDK\r\n\r\n## Problem\r\nHow do we resolve the two conflicting needs of Developers and Users while satisfy the following requirements:\r\n- Providing a clear way for Developers to introduce breaking changes as Feast evolves.\r\n- Creating a clear transition path for users integrate these changes into their systems.\r\n- Prevent code bloat resulting in Developers having to maintain too many API versions.\r\n- Introduce backward compatibility to buy users time to transition their systems to the new API.\r\n\r\n## Proposed Solution \r\nCreate and API compatibility and Support Versions Policy to document how:\r\n- What steps should developers take introduce breaking changes to the API? (ie Bump API Version, Deprecation etc.)\r\n- What \u0026 How much API compatibility guarantees can we provide to users? (ie Deprecation happens 1 minor version before removal, Backwards compatibility with older SDKs up to 1 minor release. etc.)\r\n- How do we provide a clear way for developers to announce breaking changes to users? (ie Slack? Deprecation notices? Issues? etc.)\r\n- How can we provide a clear transition path for existing users to upgrade to new versions with potentially breaking changes? (ie Highlight with `action required` in Release note what needs to be changed etc.)\r\n     ","author":{"url":"https://github.com/mrzzy","@type":"Person","name":"mrzzy"},"datePublished":"2020-05-10T04:01:29.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":6},"url":"https://github.com/687/feast/issues/687"}