OpenFeature Versioning: 1.0s and deprecations

[toddbaert]

We're setting up a meeting to talk about

• 1.0 requirements
• Runtime support and versioning implications
• Python 1.0

Meeting Link

TBD, vote on the time here.

Important

If you cannot make the meeting, feel free to put your thoughts here and we will review them in the meeting!

Conclusions

https://openfeature.dev/community/technical-guidelines/#platform-support

[Kavindu-Dodan]

Given I cannot attend the session, I will leave out my views on the highlighted points,

1.0 requirements

OpenFeature spec should define a core set of requirements. This is inspired by OIDC [1] where it defines a core set of features. From top of my mind, for OF core could mean typed evaluations, hooks and eventing. But one could also argue that eventing is an extension as that focuses on provider status which might be something additional. And something like OFREP we introduced could be part of the ecosystem.

Runtime support and versioning implications

For this, my take is that we should have strategies for each language. For example, Java 8 is still popular and has extended support [2]. And used in the corporate world making it tough to move forward. But for a language like Go, support is only there for the latest two versions [3]. Usually, projects move forward by upgrading dependencies to the last supported version (see OTel Go [4]).

We should check the same for other langs, especially checking strategies used by well-known projects and adopt them to OpenFeature

Python 1.0

We should release as soon as we finalize 1.0 requirements

[1] - https://openid.net/developers/how-connect-works/
[2] - https://endoflife.date/oracle-jdk
[3] - https://endoflife.date/go
[4] - https://github.com/open-telemetry/opentelemetry-go?tab=readme-ov-file#compatibility