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

Is "version_removed" inclusive? #4206

Closed
FranklinYu opened this issue May 23, 2019 · 9 comments
Closed

Is "version_removed" inclusive? #4206

FranklinYu opened this issue May 23, 2019 · 9 comments
Labels
question Issues where a question or problem is stated and a discussion is held to gather opinions.

Comments

@FranklinYu
Copy link
Contributor

For example, support for Public Key Pins header is removed in Chrome since 72, which means that 71 is the last Chrome with this feature. However, from the rendered compatibility table, it seems like 72 is the last version. Which one is true?

@queengooborg queengooborg added the question Issues where a question or problem is stated and a discussion is held to gather opinions. label May 23, 2019
@queengooborg
Copy link
Contributor

We've defined version_removed as exclusive, or in translation, "Browser X version Y no longer supports this feature". However, looking at the compatibility data, you do strike a good point -- it makes it seem like that version still supported it, but future versions didn't.

@Elchi3, I'd love to get your input on this one!

@Elchi3
Copy link
Member

Elchi3 commented May 24, 2019

The MDN rendering is wrong here. It is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1417902. The good news is that I think we're unblocked on this one now.

@FranklinYu
Copy link
Contributor Author

I’m not sure I understand that bug. Are we going to re-design the UI, or update the data schema?

And how is mdn/content#591 related to this issue?

@queengooborg
Copy link
Contributor

The schema will remain the same, but the renderer within Kumascript will be updated, from what I can tell in that tracking bug. That other issue is relevant because for us to show the prior browser version, we’d need to know what that version is!

@FranklinYu
Copy link
Contributor Author

FranklinYu commented May 24, 2019

Cool. In the current version, I think the affected part is

https://github.com/mdn/kumascript/blob/c4ff934bcce1dc3ce873ffda7d8ee1170e56d023/macros/Compat.ejs#L196-L215

Right? In addition, should I close this issue and track the Bugzilla bug instead?

@Elchi3
Copy link
Member

Elchi3 commented May 27, 2019

That is the affected part, correct. I think we can track here as well, so we don't forget about this issue. Implementation needs to be fixed in kumascript, though.

@foolip
Copy link
Contributor

foolip commented Feb 5, 2021

I've filed mdn/yari#6667 about getting this fixed in Yari.

@Rob--W
Copy link
Member

Rob--W commented Nov 6, 2021

This bug affects all version ranges from APIs that were dropped in Firefox for Android 79+, added in rebloor@f6ece94 (#6590).

"version_removed": "79" is meant to mean that the API is not supported in 79+.
However, the rendered compat table renders something like 48 - 79, which gives the misleading appearance that the APIs were supported in 79. Since there were no Firefox for Android releases between 68 and 79 (exclusive), the actual support range should be 48 - 68, or at most 48 - 78.

@queengooborg
Copy link
Contributor

I'm going to close this since it's a rendering issue rather than a data issue, and we have an open issue that's closer to the right spot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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

5 participants