a69f748db2
This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [prettier](https://prettier.io) ([source](https://redirect.github.com/prettier/prettier)) | [`3.5.0` -> `3.5.1`](https://renovatebot.com/diffs/npm/prettier/3.5.0/3.5.1) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes <details> <summary>prettier/prettier (prettier)</summary> ### [`v3.5.1`](https://redirect.github.com/prettier/prettier/blob/HEAD/CHANGELOG.md#351) [Compare Source](https://redirect.github.com/prettier/prettier/compare/3.5.0...3.5.1) [diff](https://redirect.github.com/prettier/prettier/compare/3.5.0...3.5.1) ##### Fix CLI crash when cache for old version exists ([#​17100](https://redirect.github.com/prettier/prettier/pull/17100) by [@​sosukesuzuki](https://redirect.github.com/sosukesuzuki)) Prettier 3.5 uses a different cache format than previous versions, Prettier 3.5.0 crashes when reading existing cache file, Prettier 3.5.1 fixed the problem. ##### Support dockercompose and github-actions-workflow in VSCode ([#​17101](https://redirect.github.com/prettier/prettier/pull/17101) by [@​remcohaszing](https://redirect.github.com/remcohaszing)) Prettier now supports the `dockercompose` and `github-actions-workflow` languages in Visual Studio Code. </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/open-feature/spec). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNjcuMSIsInVwZGF0ZWRJblZlciI6IjM5LjE2Ny4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJyZW5vdmF0ZSJdfQ==--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| specification | ||
| tools | ||
| .gitignore | ||
| .markdown-link-check-config.json | ||
| .markdownlint.yml | ||
| .prettierrc.yaml | ||
| .specignore | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| package-lock.json | ||
| package.json | ||
| renovate.json | ||
| specification.json | ||
README.md
OpenFeature Specification
OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution.
This repository describes the requirements and expectations for OpenFeature.
Design Principles
The OpenFeature specification must be designed with:
- compatibility with existing feature flag offerings.
- simple, understandable APIs.
- vendor agnosticism.
- language agnosticism.
- low/no dependency.
- extensibility.
SDKs and Client Libraries
The project aims to provide a unified API and SDK feature flag evaluation across popular technology stacks. The OpenFeature SDK provides a mechanism for interfacing with an external evaluation engine in a vendor agnostic way; it does not itself handle the flag evaluation logic.
An up-to-date SDK compatibility overview can be found here.
Tooling
This specification complies with RFC 2119 and seeks to conform to the W3C QA Framework Guidelines.
In accordance with this, some basic tooling (donated graciously by Diego Hurtado) has been employed to parse the specification and output a JSON structure of concise requirements, highlighting the particular RFC 2119 verb in question.
To parse the specification, simply type make. Please review the generated JSON files, which will appear as siblings to any of the markdown files in the /specification folder.
Style Guide
- Use code blocks for examples.
- Code blocks should be pseudocode, not any particular language, but should be vaguely "Java-esque".
- Use conditional requirements for requirements that only apply in particular situations, such as particular languages or runtimes.
- Use "sentence case" enclosed in ticks (`) when identifying entities outside of code blocks (ie:
evaluation detailsinstead ofEvaluationDetails). - Do not place line breaks into sentences, keep sentences to a single line for easier review.
- String literals appearing outside of code blocks should be enclosed in both ticks (`) and double-quotes (") (ie:
"PARSE_ERROR"). - Use "Title Case" for all titles.
- Use the imperative mood and passive voice.