-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Amend browser support policy for Safari #984
Conversation
Based on the rationale/heuristics of the browser support policy However I am curious how does it actually affect us, in terms of things we would be able to drop/stop shipping? Aren't private state and static block translation handled in app's build and they can decide whether to transpire it away based on their own babel preset? What part of the framework is still constrained by "supporting" Safari <=14.1? |
As I've been trying to figure out the incantations remaining to get ember's own build working in emberjs/ember.js#20561, I found that babel was running with a bunch of unneeded transforms over the |
Yeah. I suspect those are ultimately not used in a way that would matter, or at least we should have a path to be able to do that. If you find that to not be the case that is certainly worth calling out in the RFC. Otherwise it seems fine to do this anyway as a matter of cleanup and avoid having to run very old CI builds. |
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
I think the next action here is to draft an edit to the existing browser support policy stating that Safari will also get a percentage-usage-based support rule. |
+ <li>Google Chrome >= 103</li> | ||
+ <li>Mozilla Firefox >= 102</li> | ||
+ <li>Microsoft Edge >= 110</li> | ||
+ <li>Safari >= 16.4</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actual numbers available here: https://browsersl.ist/#q=%3E+0.25%25+and+not+dead
(based on the algorithm described in | ||
|
||
> Whichever browser version is greater/more recent out of: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the choose-the-versions algo,
Whichever browser version is greater/more recent out of:
1. The lowest/least recent version that fulfills any one of these properties:
- It is the latest version of the browser.
- It is the latest LTS/extended support version of the browser (such as Firefox ESR).
- It has at least 0.25% of global marketshare usage across mobile and desktop, based on [statcounter](https://gs.statcounter.com/).
2. The minimum version supported in the previous release
we'd have (if we needed to decide on numbers today, Feb 2nd, from: https://browsersl.ist/#q=%3E0.25%25%2C+not+dead)
Desktop
- Safari: 15.6+
- Chrome: 103+
- FireFox: 115+ (it seems firefox users are waaay better at staying up to date than Chrome or Safari)
iOS
- Safari 12.2+ (WHY?!)
Android
- Chrome 121+
- FireFox 122+
So, while initial motivations are to use the https://github.com/ef4/decorator-transforms plugin instead of the 6 babel plugins all apps need, I don't think we can decide that at this time.
But with the evergreen policy, hopefully this changes by the time ember 6.0 comes around.
For another RFC,
it may be worth giving users the option to choose their support, and we can configure their plugins accordingly.
-
ember itself, has to support this >=0.25% global market share thing.
-
apps could be more aggressive tho.
If they were to support>1%, not dead
: https://browsersl.ist/#q=%3E1%25%2C+not+dead
their ranges would look something like this:
Desktop- Chrome 109+
- FireFox 120+
- Safari 17.1+
Mobile
- Safari 16.6+
The way forward is to support Baseline, since nobody mentioned it yet. This RFC seems related, though for formal support, this is likely to be another RFC anyway I think. |
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Advance RFC #984 `"Treat Safari as an Evergreen Browser"` to Stage Ready for Release
Advance RFC #984 `"Treat Safari as an Evergreen Browser"` to Stage Released
Advance RFC #984 `"Treat Safari as an Evergreen Browser"` to Stage Recommended
Rendered
See also, browserslist query: https://browsersl.ist/#q=%3E+0.25%25+and+not+dead