Repository navigation
fix!: Fix numbering for immutable flag metadata requirement - #360
Conversation
Summary of ChangesHello @keelerm84, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves a numbering inconsistency within the OpenFeature specification. It specifically renumbers the conditional requirement concerning the immutability of flag metadata from Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Signed-off-by: Matthew Keeler <mkeeler@launchdarkly.com>
fcaa56c to
39d1bdf
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly fixes the numbering for the immutable flag metadata requirement from 1.4.14.1 to 1.4.15.1 across the specification files. The changes are consistent and accurate. I've added one comment in the Gherkin feature file to point out a pre-existing lack of clarity in a test scenario that could be improved.
| # Testing immutability requirements (Spec 1.4.15/1.4.15.1) | ||
| # Testing: flag metadata must be immutable | ||
| @immutability @spec-1.4.14.1 | ||
| @immutability @spec-1.4.15.1 |
There was a problem hiding this comment.
While the renumbering to 1.4.15.1 is correct, there's some confusion in this scenario. The spec requirement 1.4.15.1 is about Flag metadata immutability, but the scenario is named Evaluation context immutability (line 494) and also seems to test evaluation context immutability (which is covered by spec 4.1.4.1).
To improve clarity, you could consider renaming the scenario to better reflect that it tests both context and details immutability, and adding the @spec-4.1.4.1 tag.
|
Thanks @keelerm84! I'm going to merge this because it's a clear typo and doesn't change the intent defined by the spec. |
> Reopens [#431](#431), which could not be reopened after its branch moved. Same change, plus a second package. **Base of the provider-conformance stack**: [#423](#423) (assets) → [#439](#439) (Appendix F) → [#425](#425) (report schema) stack on this, but it stands on its own and can merge alone. ## What Sets up [release-please](https://github.com/googleapis/release-please) to cut the specification's releases, replacing the manual tagging step. ## Why The `vX.Y.Z` tags are created by hand. That is easy to postpone — v0.9.0 went out in July and the commits since it are unreleased — and it assembles the changelog from whoever's memory is handy. release-please proposes the version and the notes as a pull request, and tags once that pull request is merged. ## What does not change | | before | after | |---|---|---| | tag | `v0.9.0` | `v0.9.1`, `v0.10.0`, … | | next version after a breaking change | minor, while < 1.0.0 | unchanged | | who decides a release goes out | a maintainer merging | a maintainer merging the release PR | `include-component-in-tag: false` keeps the bare `vX.Y.Z` shape rather than `spec/vX.Y.Z`, and `.release-please-manifest.json` starts at `0.9.0` so numbering continues rather than restarting. `release-type: simple` because the root `package.json` is `private: true` and carries no version of its own; `simple` tracks the version in `version.txt`, which is why that file is added here. ## Scope: the specification package only One package, `.`, tagged `vX.Y.Z` as it always has been. The conformance assets under `specification/assets/provider-tck` need their own tags too — a Go consumer cannot name a version without one — but that configuration belongs beside the assets, so it is added in [#423](#423) along with the files it describes. This PR stays the general setup and can merge on its own. ## What does change, and needs a decision **Release notes become generated from conventional commits.** v0.9.0's notes were written by hand, including the `⚠️ This release contains breaking changes` callout linking #280, #306 and #360. Anything beyond the commit subjects now has to be added to the release pull request before it is merged. If the TSC would rather keep the old shape, `changelog-sections` can be tuned in a follow-up — the defaults are left here so the first release is easy to eyeball. ## What to expect on merge release-please runs on push to `main` and should open a release pull request proposing **v0.9.1**; the non-chore commits since v0.9.0 are #416, #419, #429 and #408, all `fix:` or `docs:`. Nothing is tagged until that pull request is merged, so the first run is reviewable before it has any effect. The action configuration is the shape v5 actually reads: `command` and `default-branch` are not v5 inputs, `target-branch` is, and `signoff` is a configuration-file option rather than an action input — which matters because this repository enforces DCO on the bot's own commits. --------- Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com> Signed-off-by: Todd Baert <todd.baert@dynatrace.com> Co-authored-by: Todd Baert <todd.baert@dynatrace.com>
No description provided.