As discussed in our Sept 29 community meeting, we'd like to solidify the spec and the SDKs. This may (or may not) involve releasing a 1.0 of each SDK, but will certainly involve adding some stability guarantees to the spec (see https://github.com/open-feature/spec/pull/139).
The timeline proposed is:
Oct 7th:
breaking changes are in for all SDKs, and SDKs are compliant with 0.5.0.
evaluation API and provider spec documents are marked Hardening
Oct 14th:
all providers updated with the SDK breaking changes, compliant with latest respective SDK
Oct 17th:
pending the successful updates of a majority of providers, we release SDKs with enhanced stability guarantees
this could mean SDKs release 1.0 versions, 1.0rcs, or perhaps just explicitly state they're ready for stability testing (interested in thoughts on this).
Note: The stability guarantees linked above do not prevent us from adding new features, just from breaking old ones. This effort is to provide assurances around the use of the existing interfaces, particularly providers and the application-author-facing Evaluation API.
As discussed in our Sept 29 community meeting, we'd like to solidify the spec and the SDKs. This may (or may not) involve releasing a 1.0 of each SDK, but will certainly involve adding some stability guarantees to the spec (see https://github.com/open-feature/spec/pull/139).
The timeline proposed is:
Oct 7th:
evaluation API
andprovider
spec documents are marked HardeningOct 14th:
Oct 17th:
Note: The stability guarantees linked above do not prevent us from adding new features, just from breaking old ones. This effort is to provide assurances around the use of the existing interfaces, particularly
providers
and the application-author-facingEvaluation API
.