-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: update sdks, absorb changes #1119
Conversation
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
2eae6f0
to
32cb7dd
Compare
@lukas-reining @jonathannorris @emmawillis @ajwootto @beeme1mr We've had some interest in the multi-providers in general - some people have specifically requested them in languages which don't yet implement them. This, combined win the fact we've had to duplicate some SDK logic in them here (running hooks) makes me think it's a good idea to actually move these into the SDK-proper. This would allow us to more easily share logic from the SDK, reduce duplication, and have access to internals which would make things much easier. The spec heavily implies that multi-providers are included in the SDK as well: https://openfeature.dev/specification/appendix-a#multi-provider If everyone is amenable to it, I'll create an issue to move them in. Also - @emmawillis and @ajwootto - I think I opened some org invites for you guys some time ago, but they've been closed. If you're interested in being in the org please let me know and I'll invite you guys (no obligation). |
This makes sense to me @toddbaert. So from my side let's go for this. |
yea makes sense to me to move it. |
cc @ajwootto @emmawillis