open-feature
feat: stabilize - evaluation, providers, harden - hooks, events, context
This PR:
- stabilizes evaluation API
- stabilizes providers
- hardens hooks, events and context
- hardens all "static context" (client-side) points
This is a pretty substantial step.
stable means that we have no more leeway at all in SDKs - any breaking changes to the parts of the SDK implementing stable APIs means a new major version of the SDK is required, without exception.
I've also opted to "harden" the static context paradigm since we have numerous client implementations in the wild, in particular React and Angular, but also Android. There could still be breaking changes here but the bar is higher. I think this is how we're acting already with regards to these APIs, in all honesty.
I did not promote the context propagation sub-section, or the new tracking section - these are relatively new, though I'm open to opinions on hardening these further.
Potential blockers:
- https://github.com/open-feature/go-sdk/issues/389
- https://github.com/open-feature/spec/issues/270
One other thing to point out is that hook data isn't widely implemented yet, so we could mark that subsection experimental... however I don't see much risk with it.
One other thing to point out is that hook data isn't widely implemented yet, so we could mark that subsection experimental... however I don't see much risk with it.
Yeah, it is very new so that seems like a good idea.
Would it make sense to focus on experimental -> hardening in this PR and work on hardening -> stable in a separate PR? As noted already, the implications of moving from hardening to stable are significant and I think that requires more thought and care. I think a review of the current implementations across the SDKs is warranted to look for any possible changes we want to make before marking any part of the spec stable.
Would it make sense to focus on experimental -> hardening in this PR and work on hardening -> stable in a separate PR? As noted already, the implications of moving from hardening to stable are significant and I think that requires more thought and care. I think a review of the current implementations across the SDKs is warranted to look for any possible changes we want to make before marking any part of the spec stable.
My main object here is the stable changes, not so much the hardening ones. I'm fine with this PR taking a while, I'm not sure I see so much value in separating them, but lets see what others think.
I've opened https://github.com/open-feature/spec/pull/315, which based on feedback, I think we should agree on first.
Related: I opened https://github.com/open-feature/go-sdk/issues/389, which proposes a breaking change to the initialization and shutdown functions (sections 2.4 and 2.5 of the spec) of the go-sdk.