Skip to content
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

Should a support statement with flags get version_removed when unflagged? #14777

Closed
gsnedders opened this issue Feb 1, 2022 · 4 comments
Closed
Labels
docs ✍️ Issues or pull requests regarding the documentation of this project. question ❔ Issues where a question or problem is stated and a discussion is held to gather opinions.

Comments

@gsnedders
Copy link
Contributor

Seemingly we don't currently have consensus here. Sometimes they get version_removed, sometimes they don't. We should have a policy here, and enforce it with a lint (at least in the case when the version_removed would align with version_added without a flag).

For example, api.AnimationTimeline has:

          "firefox": [
            {
              "version_added": "75"
            },
            {
              "version_added": "63",
              "flags": [
                {
                  "type": "preference",
                  "name": "dom.animations-api.timelines.enabled",
                  "value_to_set": "true"
                }
              ]
            }
          ],

Which results in Yari showing:

MDN screenshot, including "From version 63: this feature is behind…"

Whereas api.CanvasRenderingContext2D.createConicGradient has:

            "firefox": [
              {
                "version_added": "90"
              },
              {
                "version_added": "86",
                "version_removed": "90",
                "flags": [
                  {
                    "type": "preference",
                    "name": "canvas.createConicGradient.enabled"
                  }
                ]
              }
            ],

Which results in Yari showing:

MDN screenshot, including "Removed in 90 and later"

@queengooborg queengooborg added docs ✍️ Issues or pull requests regarding the documentation of this project. question ❔ Issues where a question or problem is stated and a discussion is held to gather opinions. labels Feb 1, 2022
@queengooborg
Copy link
Collaborator

In BCD, we use a version_removed for the flags when the flag itself has been removed, rather than when it's enabled by default. However, this isn't a defined policy, and I personally feel that it would be simpler just to mark the support behind a flag as removed once it's enabled by default. We should definitely plan a policy and document it.

@gsnedders
Copy link
Contributor Author

See also #16287 which added a guideline here.

That said, given the guideline says:

Set version_removed to the earliest applicable version from these conditions. For example, if Chrome 90 enabled the flag by default, the feature could no longer be toggled off by disabling the flag in Chrome 96, and finally the flag was removed by Chrome 98, then set version_removed to 90 as it is the earliest applicable version.

How does this work with preview as a version? Do we treat preview as the earliest applicable version in all eternity, or do we change it following a release?

@queengooborg
Copy link
Collaborator

#16287 should probably have marked this issue closed, right?

In regards to preview, preview should always be considered the most recent (latest) version, since it's data for an upcoming/beta release.

@queengooborg
Copy link
Collaborator

queengooborg commented Aug 6, 2023

I'm going to mark this as closed assuming that #16287 or #16637 has covered this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs ✍️ Issues or pull requests regarding the documentation of this project. question ❔ Issues where a question or problem is stated and a discussion is held to gather opinions.
Projects
None yet
Development

No branches or pull requests

2 participants