profile
viewpoint
Albert Yu nightire @choice-form @choice-open @very-geek Guiyang, China http://www.very-geek.com As a designeer, I hope you can prove me wrong.

nightire/dearann 3

Web client part for Dear Ann's website

nightire/dotfiles-reference 2

:wrench: .files, including ~/.osx — sensible hacker defaults for OS X

nightire/ember-starter 2

HTML5 + Ember.js + CoffeeScript + Mocha/Chai/Karma + Sass/Compass/Susy + Grunt

nightire/ember-decorators 1

Useful decorators for Ember applications.

nightire/19wu 0

19wu - 卖活动票的小屋(已开始开发)

nightire/algortihms_challenges 0

Solutions to programming challenges and algorithmic problems

nightire/angular-starter 0

HTML5 + Angular + CoffeeScript + Mocha/Chai/Karma + Sass/Compass/Susy + Grunt

nightire/babel 0

Turn ES6 code into readable vanilla ES5 with source maps

nightire/babel-plugin-handbook 0

How to create Babel plugins

pull request commentemberjs/rfcs

New browser support policy

Regarding iOS, I think it is important to note that this is not totally up to the users - there are older devices which cannot be updated to an iOS version that runs Safari 14+. Of course these are older models, but I have seen people keep (happily) using them, and for them the only way forward would be to buy a new device. Especially with iPads I've met quite a few people still running very old devices. We don't have to care about those edge cases, but we should keep it in mind.

In this concrete example, after looking it up, it probably doesn't matter that much as all devices that support iOS 13 also support iOS 14. So I guess we might as well require iOS 14 out of the box. So :+1: from me.

pzuraq

comment created time in 41 minutes

created repositorysmartepsh/umbrella_deps

created time in 43 minutes

startedpeaksandpies/universal-analytics

started time in 2 hours

startedvacu/electron-google-analytics

started time in 2 hours

startedremaxjs/remax

started time in 2 hours

delete branch very-geek/octane-sandbox

delete branch : renovate/ember

delete time in 7 hours

push eventvery-geek/octane-sandbox

Renovate Bot

commit sha eb209a2c18dbb8410636df049018e996288a8e1e

chore(renovate): update dependency ember-data to v3.23.0 | datasource | package | from | to | | ---------- | ---------- | ------ | ------ | | npm | ember-data | 3.22.1 | 3.23.0 |

view details

push time in 7 hours

PR merged very-geek/octane-sandbox

chore(renovate): update dependency ember-data to v3.23.0 优先级: 中 类型: 问题

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
ember-data 3.22.1 -> 3.23.0 age adoption passing confidence

Release Notes

<details> <summary>emberjs/data</summary>

v3.23.0

Compare Source

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: 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 has been generated by WhiteSource Renovate. View repository job log here.

+59 -59

0 comment

2 changed files

renovate[bot]

pr closed time in 7 hours

PR opened very-geek/octane-sandbox

chore(renovate): update dependency ember-data to v3.23.0

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
ember-data 3.22.1 -> 3.23.0 age adoption passing confidence

Release Notes

<details> <summary>emberjs/data</summary>

v3.23.0

Compare Source

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: 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 has been generated by WhiteSource Renovate. View repository job log here.

+59 -59

0 comment

2 changed files

pr created time in 7 hours

create barnchvery-geek/octane-sandbox

branch : renovate/ember

created branch time in 7 hours

startedsemantic-release/semantic-release

started time in 8 hours

Pull request review commentemberjs/rfcs

Deprecate old manager capabilities versions

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): Ember.js+RFC PR: https://github.com/emberjs/rfcs/pull/686+---++# Deprecate Old Manager Capabilities++## Summary++Deprecate older capabilities versions from the various manager APIs.++## Motivation++In the 3.x cycle, Ember introduced a series of new low-level APIs for managing+template constructs:++- [Component managers](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md)+- [Modifier managers](https://github.com/emberjs/rfcs/blob/master/text/0373-Element-Modifier-Managers.md)+- [Helper managers](https://github.com/emberjs/rfcs/blob/master/text/0625-helper-managers.md)++These APIs were expected to evolve more quickly than the higher level APIs they+enabled, and they have in fact done so. They do this via the `capabilities`+mechanism, where users can specify a version of capabilities that they want.+This allows Ember to change these APIs as needs evolve, as long as the prior+capabilities can still be maintained.++Maintaining the prior capabilities versions has a cost however in terms of+maintenance burden, and sometimes requires us to keep around a decent amount of+extra code or internal features. Deprecating these versions for the next major+release will help clean up code internally overall.++## Transition Path++Users should update to the most recent manager versions, which will not be+deprecated. The versions which are being deprecated include:++- Component Managers+  - 3.4+- Modifier Managers+  - 3.13++The versions that are still supported are:++- Component Managers+  - 3.13+- Modifier Managers+  - 3.22+- Helper Managers+  - 3.23++## How We Teach This++In general, the guides won't need to be updated as there isn't guide material+for these manager APIs. We should update the API docs for them to remove the+deprecated capabilities versions. In addition, we should add deprecation guides+for each of the deprecated versions.++Guides as follows.++### Component Managers++#### 3.4++Any component managers using the `3.4` capabilities should update to the most+recent component capabilities that are available, currently `3.13`. In `3.13`,+the only major change is that update hooks are no longer called by default. If+you need update hooks, use the `updateHook` capability:++```js+capabilities({+  updateHook: true,+});+```++### Modifier Managers++#### 3.13++Any modifier managers using the `3.13` capabilities should update to the most+recent modifier capabilities, currently `3.22`. In `3.22`, the major changes+are:++1. The modifier definition, associated via `setModifierManager` is passed+   directly to `create`, rather than a factory wrapper class. Previously, you+   would access the class via the `class` property on the factory wrapper:++   ```js+   // before+   class CustomModifierManager {+     createModifier(Definition, args) {+       return new Definition.class(args);+     }+   }+   ```++   This can be updated to use the definition directly:++   ```js+   // after+   class CustomModifierManager {+     createModifier(Definition, args) {+       return new Definition(args);+     }+   }+   ```

Can you update these examples to call out the capabilities bit (which is required, but not included)?

pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

Deprecate old manager capabilities versions

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): Ember.js+RFC PR: https://github.com/emberjs/rfcs/pull/686+---++# Deprecate Old Manager Capabilities++## Summary++Deprecate older capabilities versions from the various manager APIs.++## Motivation++In the 3.x cycle, Ember introduced a series of new low-level APIs for managing+template constructs:++- [Component managers](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md)+- [Modifier managers](https://github.com/emberjs/rfcs/blob/master/text/0373-Element-Modifier-Managers.md)+- [Helper managers](https://github.com/emberjs/rfcs/blob/master/text/0625-helper-managers.md)++These APIs were expected to evolve more quickly than the higher level APIs they+enabled, and they have in fact done so. They do this via the `capabilities`+mechanism, where users can specify a version of capabilities that they want.+This allows Ember to change these APIs as needs evolve, as long as the prior+capabilities can still be maintained.++Maintaining the prior capabilities versions has a cost however in terms of+maintenance burden, and sometimes requires us to keep around a decent amount of+extra code or internal features. Deprecating these versions for the next major+release will help clean up code internally overall.++## Transition Path++Users should update to the most recent manager versions, which will not be+deprecated. The versions which are being deprecated include:++- Component Managers+  - 3.4+- Modifier Managers+  - 3.13++The versions that are still supported are:++- Component Managers+  - 3.13+- Modifier Managers+  - 3.22+- Helper Managers+  - 3.23++## How We Teach This++In general, the guides won't need to be updated as there isn't guide material+for these manager APIs. We should update the API docs for them to remove the+deprecated capabilities versions. In addition, we should add deprecation guides+for each of the deprecated versions.++Guides as follows.++### Component Managers++#### 3.4++Any component managers using the `3.4` capabilities should update to the most+recent component capabilities that are available, currently `3.13`. In `3.13`,+the only major change is that update hooks are no longer called by default. If+you need update hooks, use the `updateHook` capability:++```js+capabilities({+  updateHook: true,+});+```++### Modifier Managers++#### 3.13++Any modifier managers using the `3.13` capabilities should update to the most+recent modifier capabilities, currently `3.22`. In `3.22`, the major changes+are:++1. The modifier definition, associated via `setModifierManager` is passed+   directly to `create`, rather than a factory wrapper class. Previously, you+   would access the class via the `class` property on the factory wrapper:++   ```js+   // before+   class CustomModifierManager {+     createModifier(Definition, args) {+       return new Definition.class(args);+     }+   }+   ```++   This can be updated to use the definition directly:++   ```js+   // after+   class CustomModifierManager {+     createModifier(Definition, args) {+       return new Definition(args);+     }+   }+   ```++2. Args are both lazy and autotracked by default. This means that in order to+   track an argument value, you must actually use it in your modifier. If you do+   not, the modifier will not update when the value changes.++   If you still need the modifier to update whenever a value changes, even if it+   was not used, you can manually access every value in the modifiers+   `installModifier` and `updateModifier` lifecycle hooks:++   ```js+   function consumeArgs(args) {+     for (let key in args.named) {+       // consume value+       args.named[key];+     }++     for (let i = 0; i < args.positional.length; i++) {+       // consume value+       args.positional[i];+     }+   }++   class CustomModifierManager {+     installModifier(bucket, element, args) {+       consumeArgs(args);++       // ...+     }++     updateModifier(bucket, args) {+       consumeArgs(args);++       // ...+     }+   }+   ```++   In general this should be avoided, however, and users who are writing+   modifiers should instead use the value if they want it to be tracked by the+   modifier.++## Drawbacks++- There will be some minor churn in the ecosystem as managers update, but this+  is outweighed by the lowered maintenance burden in general for this+  functionality.

FWIW, this is a significant issue. Since updating ember-modifer to use 3.22 capabilities is a breaking change and ember-cli does not currently support (not well at least) having multiple versions of a given package in the build we have to do a bit of hoop jumping to accomodate this.

Regardless, I think we should do this, but ^ is a very real issue that will need to be addressed before the actual deprecation lands.

pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.++The supported versions of browsers are determined at the time of each _minor_+release of Ember and Ember Data. In the release blog post, we will specify+which versions of browsers are supported for this minor version, to keep users+informed as usage changes.++_Within_ a minor version, support works as follows:++1. Support for a given browser version is _never_ removed.+2. Support is _added_ for any new versions of a browser that have been released+   while the minor is still supported.++So for instance, if we were to release Ember 4.4 with support for Chrome 92, 93,+and 94, then bugfixes and security fixes for those versions of Chrome will be+supported until 4.4 is no longer an LTS, following the LTS support matrix. In+addition, if Chrome were to release version 95 while 4.4 is still actively+supported, then 4.4 will also support Chrome 95.++### Non-evergreen browsers++Ember and Ember Data will support the following versions of non-evergreen+browsers:++- Desktop+  - Safari: 14+- Mobile+  - Safari: 14++These versions will continue to be supported until support is explicitly dropped+via a new RFC, and dropping support for any version of these browsers will+require a new **major** release.++In addition, all new major releases of these browsers will be supported as they+are released. Like with evergreen browsers, support is retroactively added to+any minor version of Ember which is still supported.++#### Note on the versions chosen++The versions chosen here are the latest versions of Safari, which having just+been released this year, do not have 100% adoption. As such, there are still a+significant number of users who are using previous versions of Safari. However,+by the time this support policy is enacted and a new major version of Ember is+released, this number will likely have shifted significantly.++In addition, since Ember will not drop support for any version of Safari until+the next major release after this policy is enacted (v5), this decision strikes+a balance between enabling usage of new APIs and patterns, while still providing+support for users who are stuck on older versions of Safari. While we are+leaping ahead now, in the coming years the majority of users will upgrade beyond+this version, and eventually we will be supporting a much older version of+Safari than is actually used in practice.++Supporting Safari 14 and above means that Ember can safely use the following JS+features:++- The BigInt data type.+- Creating custom instances of EventTarget.+- Logical assignment operators.+- Public class fields.++In its own internal code, without needing to worry about polyfills. Of course,+polyfills can still be provided by Ember applications, and may continue to work -+they are just not explicitly supported.++## What support means++This policy governs two major aspects of Ember and Ember Data:++1. When the framework adopts new browser features+2. How the framework responds to bug reports++Ember and Ember Data _may_ introduce new browser feature usage in any _minor_+version release of Ember, provided the feature is supported in all browsers that+are supported in this policy at the time the the version in released.++Ember and Ember Data _may_ introduce new browser feature usage in any _patch_+version release of Ember, provided the feature is supported in all browsers that+were supported in this policy at the time the _minor_ that the patch is applied+to was released. In other words, no breakage can or should occur due to new+browser feature usage in _any_ patch release, and if it does, it is a bug.++For bug reports, support is determined by combining our existing Ember version+support policy with the browser versions that were supported at the time an+Ember version was released. This means Ember will work as time and resourcing is+available to fix any browser specific issues that occur in:++1. The current stable and LTS releases of Ember and Ember Data+2. For browsers that were supported by those versions when they were relased++For the previous LTS release, only security bugfixes will be supported,+following the existing LTS policy.++## Future changes to the policy++This policy is not meant to be immutable. Over time, new browsers could be added+to the support matrix, and explicit exceptions could be added for "critical+internet infrastructure".++For example, it was well known that Google's search crawler used a very old+version of Google Chrome for a very long time. It no longer does and is+regularly updated, but during that time frame it was important to support that+version of Chrome. Likewise, it was very important to support IE11 for a very+long time since it had a large usage percentage, especially in corporate+environments. While none of these cases are known to exist at the time of this+writing, if one should arise it may be added explicitly via RFC.++Future RFCs may amend this policy in a strictly additive way without requiring+a major version bump in Ember. Newly supported browsers will begin being+supported in the next minor version of Ember after the updated support policy is+implemented.++Future RFCs that amend this policy to _remove_ support for a browser will+_require_ a major version of Ember to implement.++## Implementation++This policy drops support for a major browser, and therefore can only be+implemented with a major version bump.++## How we teach this

Can you add an entries to the list below:

  • for maintaining a concrete list of what is supported by a given minor version (and having that)
  • to indicate that the release blog post will call out any dropped versions for that minor
pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari

We also need to ensure that testing is supported, can you add a section to explicitly call out headless chrome and headless firefox (possibly under testing)?

pzuraq

comment created time in 11 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.

FWIW, I worry about this explicit choice (dropping browsers without a major bump). How does this relate to our SemVer commitment?

pzuraq

comment created time in 11 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.++The supported versions of browsers are determined at the time of each _minor_+release of Ember and Ember Data. In the release blog post, we will specify+which versions of browsers are supported for this minor version, to keep users+informed as usage changes.++_Within_ a minor version, support works as follows:++1. Support for a given browser version is _never_ removed.+2. Support is _added_ for any new versions of a browser that have been released+   while the minor is still supported.++So for instance, if we were to release Ember 4.4 with support for Chrome 92, 93,+and 94, then bugfixes and security fixes for those versions of Chrome will be+supported until 4.4 is no longer an LTS, following the LTS support matrix. In+addition, if Chrome were to release version 95 while 4.4 is still actively+supported, then 4.4 will also support Chrome 95.++### Non-evergreen browsers++Ember and Ember Data will support the following versions of non-evergreen+browsers:++- Desktop+  - Safari: 14+- Mobile+  - Safari: 14++These versions will continue to be supported until support is explicitly dropped+via a new RFC, and dropping support for any version of these browsers will+require a new **major** release.++In addition, all new major releases of these browsers will be supported as they+are released. Like with evergreen browsers, support is retroactively added to+any minor version of Ember which is still supported.++#### Note on the versions chosen++The versions chosen here are the latest versions of Safari, which having just+been released this year, do not have 100% adoption. As such, there are still a+significant number of users who are using previous versions of Safari. However,+by the time this support policy is enacted and a new major version of Ember is+released, this number will likely have shifted significantly.++In addition, since Ember will not drop support for any version of Safari until+the next major release after this policy is enacted (v5), this decision strikes+a balance between enabling usage of new APIs and patterns, while still providing+support for users who are stuck on older versions of Safari. While we are+leaping ahead now, in the coming years the majority of users will upgrade beyond+this version, and eventually we will be supporting a much older version of+Safari than is actually used in practice.++Supporting Safari 14 and above means that Ember can safely use the following JS+features:++- The BigInt data type.+- Creating custom instances of EventTarget.+- Logical assignment operators.+- Public class fields.++In its own internal code, without needing to worry about polyfills. Of course,+polyfills can still be provided by Ember applications, and may continue to work -+they are just not explicitly supported.++## What support means++This policy governs two major aspects of Ember and Ember Data:++1. When the framework adopts new browser features+2. How the framework responds to bug reports++Ember and Ember Data _may_ introduce new browser feature usage in any _minor_+version release of Ember, provided the feature is supported in all browsers that+are supported in this policy at the time the the version in released.++Ember and Ember Data _may_ introduce new browser feature usage in any _patch_+version release of Ember, provided the feature is supported in all browsers that+were supported in this policy at the time the _minor_ that the patch is applied+to was released. In other words, no breakage can or should occur due to new+browser feature usage in _any_ patch release, and if it does, it is a bug.++For bug reports, support is determined by combining our existing Ember version+support policy with the browser versions that were supported at the time an+Ember version was released. This means Ember will work as time and resourcing is+available to fix any browser specific issues that occur in:++1. The current stable and LTS releases of Ember and Ember Data+2. For browsers that were supported by those versions when they were relased++For the previous LTS release, only security bugfixes will be supported,+following the existing LTS policy.++## Future changes to the policy++This policy is not meant to be immutable. Over time, new browsers could be added+to the support matrix, and explicit exceptions could be added for "critical+internet infrastructure".++For example, it was well known that Google's search crawler used a very old+version of Google Chrome for a very long time. It no longer does and is+regularly updated, but during that time frame it was important to support that+version of Chrome. Likewise, it was very important to support IE11 for a very+long time since it had a large usage percentage, especially in corporate+environments. While none of these cases are known to exist at the time of this+writing, if one should arise it may be added explicitly via RFC.++Future RFCs may amend this policy in a strictly additive way without requiring+a major version bump in Ember. Newly supported browsers will begin being+supported in the next minor version of Ember after the updated support policy is+implemented.++Future RFCs that amend this policy to _remove_ support for a browser will+_require_ a major version of Ember to implement.++## Implementation++This policy drops support for a major browser, and therefore can only be+implemented with a major version bump.++## How we teach this++- A blog post explaining the policy with a link to this RFC will be posted.+- Browser support policy will be linked in repo

What is the actual policy? This RFC likely contains all the information, but it doesn't seem like it is quite in the format that we would want?

pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.

I believe that you intend for this to be dropped without a major version bump, can you explicitly call this out?

pzuraq

comment created time in 11 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.++The supported versions of browsers are determined at the time of each _minor_+release of Ember and Ember Data. In the release blog post, we will specify+which versions of browsers are supported for this minor version, to keep users+informed as usage changes.++_Within_ a minor version, support works as follows:++1. Support for a given browser version is _never_ removed.+2. Support is _added_ for any new versions of a browser that have been released+   while the minor is still supported.++So for instance, if we were to release Ember 4.4 with support for Chrome 92, 93,+and 94, then bugfixes and security fixes for those versions of Chrome will be+supported until 4.4 is no longer an LTS, following the LTS support matrix. In+addition, if Chrome were to release version 95 while 4.4 is still actively+supported, then 4.4 will also support Chrome 95.++### Non-evergreen browsers++Ember and Ember Data will support the following versions of non-evergreen+browsers:++- Desktop+  - Safari: 14+- Mobile+  - Safari: 14++These versions will continue to be supported until support is explicitly dropped+via a new RFC, and dropping support for any version of these browsers will+require a new **major** release.++In addition, all new major releases of these browsers will be supported as they+are released. Like with evergreen browsers, support is retroactively added to+any minor version of Ember which is still supported.++#### Note on the versions chosen++The versions chosen here are the latest versions of Safari, which having just+been released this year, do not have 100% adoption. As such, there are still a+significant number of users who are using previous versions of Safari. However,+by the time this support policy is enacted and a new major version of Ember is+released, this number will likely have shifted significantly.++In addition, since Ember will not drop support for any version of Safari until+the next major release after this policy is enacted (v5), this decision strikes+a balance between enabling usage of new APIs and patterns, while still providing+support for users who are stuck on older versions of Safari. While we are+leaping ahead now, in the coming years the majority of users will upgrade beyond+this version, and eventually we will be supporting a much older version of+Safari than is actually used in practice.++Supporting Safari 14 and above means that Ember can safely use the following JS+features:++- The BigInt data type.+- Creating custom instances of EventTarget.+- Logical assignment operators.+- Public class fields.++In its own internal code, without needing to worry about polyfills. Of course,+polyfills can still be provided by Ember applications, and may continue to work -+they are just not explicitly supported.++## What support means++This policy governs two major aspects of Ember and Ember Data:++1. When the framework adopts new browser features+2. How the framework responds to bug reports++Ember and Ember Data _may_ introduce new browser feature usage in any _minor_+version release of Ember, provided the feature is supported in all browsers that+are supported in this policy at the time the the version in released.++Ember and Ember Data _may_ introduce new browser feature usage in any _patch_+version release of Ember, provided the feature is supported in all browsers that+were supported in this policy at the time the _minor_ that the patch is applied+to was released. In other words, no breakage can or should occur due to new+browser feature usage in _any_ patch release, and if it does, it is a bug.++For bug reports, support is determined by combining our existing Ember version+support policy with the browser versions that were supported at the time an+Ember version was released. This means Ember will work as time and resourcing is+available to fix any browser specific issues that occur in:++1. The current stable and LTS releases of Ember and Ember Data+2. For browsers that were supported by those versions when they were relased++For the previous LTS release, only security bugfixes will be supported,+following the existing LTS policy.++## Future changes to the policy++This policy is not meant to be immutable. Over time, new browsers could be added+to the support matrix, and explicit exceptions could be added for "critical+internet infrastructure".++For example, it was well known that Google's search crawler used a very old+version of Google Chrome for a very long time. It no longer does and is+regularly updated, but during that time frame it was important to support that+version of Chrome. Likewise, it was very important to support IE11 for a very+long time since it had a large usage percentage, especially in corporate+environments. While none of these cases are known to exist at the time of this+writing, if one should arise it may be added explicitly via RFC.++Future RFCs may amend this policy in a strictly additive way without requiring+a major version bump in Ember. Newly supported browsers will begin being+supported in the next minor version of Ember after the updated support policy is+implemented.++Future RFCs that amend this policy to _remove_ support for a browser will+_require_ a major version of Ember to implement.++## Implementation++This policy drops support for a major browser, and therefore can only be+implemented with a major version bump.++## How we teach this++- A blog post explaining the policy with a link to this RFC will be posted.+- Browser support policy will be linked in repo+- Browser support policy will be added to the website+- Browser support policy will have an announcement in the Ember Times++## Drawbacks++- The proposed policy makes Safari the new "lowest common denominator" browser,+  replacing IE11. Since the supported versions of Safari will continue to be+  supported indefinitely, we will not be able to use any new browser features+  added afterwards without another major version. In particular, the spec for+  `WeakRef` has finally been stabilized, and this is something we'll likely want+  to make use of in the not-to-distant future.++  While this is true, it does not impact the immediate roadmap for Ember in the+  next few years. When the time comes, we can update our browser support policy+  again, and release a new major version.++## Alternatives
  • Drop IE11 but not add more definition to support (keeping it as a case by case determination by the core teams)
pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.++The supported versions of browsers are determined at the time of each _minor_+release of Ember and Ember Data. In the release blog post, we will specify+which versions of browsers are supported for this minor version, to keep users+informed as usage changes.++_Within_ a minor version, support works as follows:++1. Support for a given browser version is _never_ removed.+2. Support is _added_ for any new versions of a browser that have been released+   while the minor is still supported.++So for instance, if we were to release Ember 4.4 with support for Chrome 92, 93,+and 94, then bugfixes and security fixes for those versions of Chrome will be+supported until 4.4 is no longer an LTS, following the LTS support matrix. In+addition, if Chrome were to release version 95 while 4.4 is still actively+supported, then 4.4 will also support Chrome 95.

How do you know a version is dropped? What does a user actually have to do to know a specfic chrome version they care about is no longer supported?

pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.

Source? It is not clear to me that there is any actual existing policy (other than that we officially support IE11 without polyfills)... 🤔

pzuraq

comment created time in 11 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on+   [statcounter](https://gs.statcounter.com/).++This policy will allow Ember to generally support the most recent 2-3 versions+of the browser, and account for versions which may become temporary transition+points. For example, when MS Edge made the switch to the new Chromium-backed+version, the last non-Chromium version saw higher usage for a slightly longer+period of time as the update process was not as standard, and required an+explicit opt-in. These transitionary periods are important, but generally+speaking temporary, and once the usage drops below the threshold Ember can drop+support at that point.++The supported versions of browsers are determined at the time of each _minor_+release of Ember and Ember Data. In the release blog post, we will specify+which versions of browsers are supported for this minor version, to keep users+informed as usage changes.++_Within_ a minor version, support works as follows:++1. Support for a given browser version is _never_ removed.+2. Support is _added_ for any new versions of a browser that have been released+   while the minor is still supported.++So for instance, if we were to release Ember 4.4 with support for Chrome 92, 93,+and 94, then bugfixes and security fixes for those versions of Chrome will be+supported until 4.4 is no longer an LTS, following the LTS support matrix. In+addition, if Chrome were to release version 95 while 4.4 is still actively+supported, then 4.4 will also support Chrome 95.++### Non-evergreen browsers++Ember and Ember Data will support the following versions of non-evergreen+browsers:++- Desktop+  - Safari: 14+- Mobile+  - Safari: 14++These versions will continue to be supported until support is explicitly dropped+via a new RFC, and dropping support for any version of these browsers will+require a new **major** release.++In addition, all new major releases of these browsers will be supported as they+are released. Like with evergreen browsers, support is retroactively added to+any minor version of Ember which is still supported.

This language confuses me. What versions within the major are supported? Is 14.0.0 supported after 14.1.0 is out?

pzuraq

comment created time in 10 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari++Any browser which is not listed here may work, but is not explicitly supported.+In addition, in order to recategorize browsers as evergreen or non-evergreen, a+new RFC must be submitted to update the support policy.++So for instance, if Safari were to begin automatically updating its version+independently of macOS/iOS versions, and thus fulfill the criteria for evergreen+browsers, it would still be treated as a non-evergreen browser until this policy+is updated. This will prevent sudden and unexpected changes in the support+matrix for Ember users.++### Evergreen browsers++Ember and Ember Data will support **all** versions of evergreen browsers which+meet any of the following criteria:++1. It is the latest version of the browser.+2. It is the latest LTS/extended support version of the browser (such as Firefox ESR).+3. It has at least **0.25%** marketshare usage, based on

Can you clarify this? Does this mean 0.25% global market share across mobile and desktop?

pzuraq

comment created time in 11 hours

Pull request review commentemberjs/rfcs

New browser support policy

+---+Stage: Accepted+Start Date: 2020-11-28+Release Date: Unreleased+Release Versions:+  ember-source: vX.Y.Z+  ember-data: vX.Y.Z+Relevant Team(s): All+RFC PR: https://github.com/emberjs/rfcs/pull/685+---++# New Browser Support Policy++## Summary++Establishes a new browser support policy for the next major release of Ember and+Ember Data.++## Motivation++With Microsoft's recent release of the new Chromium-based Edge browser, which+has a compatibility mode for Internet Explorer built in, many frameworks, tools,+libraries, and websites have begun finally dropping support for the aging+browser. In order to unlock the latest browser features and continue improving+the framework as a whole, Ember should also drop support in the next major+release.++In dropping support for Internet Explorer, we will need a new browser support+policy. Until now Internet Explorer has been the "lowest common denominator"+for all features. It is a very old browser that no longer releases new versions,+and was not "evergreen" (e.g. constantly updating) even when it was. As such,+Ember has been very stable from release to release, as supporting any version of+Internet Explorer meant we simply could not use any new browser features.++With modern evergreen browser release cycles, where browsers release regularly+and users are generally on one of the more recent versions of a browser, this+dynamic changes. We cannot set an explicit version to support anymore, because+it would be impractical - Chrome alone releases a new version every 6 weeks.+Setting an explicit lowest-supported-version would lock us into having to+support a huge number of older browsers, many of which are entirely unused.++Conversely, however, tracking the latest release of a browser may not be enough+stability for Ember apps. If Ember were to adopt a new browser feature+immediately after its release, even though many web users were still using a+previous version, it would cause many Ember apps to either break, or be unable+to update until their users had also updated to the latest browser. Even a+rolling `N - 1` or `N - 2` support policy, where the last 1 or 2 versions are+supported, may not be enough. Many users were stuck in the recent Edgium update+for some time, for instance.++This RFC seeks to establish a new support policy that addresses these issues+with a new set of heuristics. These heuristics distinguish between two types of+browsers which are supported:++- **Evergreen browsers**, those which have adopted a continuous update policy+  and generally keep their users up-to-date automatically.+- **Non-evergreen browsers**, which have more complicated support patterns that+  may prevent users from updating regularly.++Depending on which category a browser falls into, different rules will be+applied. This will allow us to effectively support browsers which release+frequently, such as Chrome, and browsers which do not, such as Safari.++## Existing Policy++The existing policy is listed here for documentation purposes.++- Desktop++    1. Google Chrome, Mozilla Firefox, MS Edge, Mac Safari++        - The current and previous stable releases are supported.++    2. Internet Explorer++        - Only Internet Explorer 11 is supported.++- Mobile++    1. All++        - All mobile browsers may work but are not explicitly supported.++Any browsers not listed here may work but are not explicitly supported.++## Proposed policy++In the new support policy, we define two categories of browsers:++1. **Evergreen browsers**, which are browsers that:++   * Support using the latest version on all supported platforms (e.g. you can+     use the latest Chrome an any supported version of Windows, macOS, Android,+     etc. The browser is versioned independently from the operating system).+   * Automatically update whenever a new version is available.++2. **Non-evergreen browsers**, which are any browsers which do not meet the+   criteria of evergreen browsers. For instance, Safari is a supported browser+   whose version is tied to the version of macOS and iOS that users use. As+   users will often wait to update their operating system, many users lag behind+   on the version of Safari they are using, so it cannot be considered+   evergreen.++Using these categories, Ember will support the following browsers:++- Evergreen+  - Desktop+      1. Google Chrome/Chromium+      2. Mozilla Firefox+      3. Microsoft Edge+  - Mobile+      1. Google Chrome+      2. Mozilla Firefox++- Non-evergreen+  - Desktop+    1. Safari+  - Mobile+    1. Safari

Since we are basically just listing specific browsers, I find the evergreen / non-evergreen split to be more confusing than helpful here. It is super good as an explanation of the policy decisions, but not for the policy itself (IMHO).

Can you merge the lists?

pzuraq

comment created time in 11 hours

pull request commentemberjs/rfcs

New browser support policy

Strongly agreed that we shouldn't be supporting anything lower than 13, and the LTS point is one I hadn't fully taken onboard. I think given that 4.4 LTS would be mid-to-late fall, I think Safari 14 as the cutoff is perfectly reasonable.

pzuraq

comment created time in 14 hours

delete branch very-geek/octane-sandbox

delete branch : renovate/eslint

delete time in 15 hours

push eventvery-geek/octane-sandbox

Renovate Bot

commit sha 9a9d73510d7807b7f51ea3e4ba677212aa79bba9

chore(renovate): update eslint related to v4.9.0 | datasource | package | from | to | | ---------- | -------------------------------- | ----- | ----- | | npm | @typescript-eslint/eslint-plugin | 4.8.2 | 4.9.0 | | npm | @typescript-eslint/parser | 4.8.2 | 4.9.0 |

view details

push time in 15 hours

PR merged very-geek/octane-sandbox

chore(renovate): update eslint related to v4.9.0 优先级: 中 类型: 问题

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@typescript-eslint/eslint-plugin 4.8.2 -> 4.9.0 age adoption passing confidence
@typescript-eslint/parser 4.8.2 -> 4.9.0 age adoption passing confidence

Release Notes

<details> <summary>typescript-eslint/typescript-eslint</summary>

v4.9.0

Compare Source

Bug Fixes
  • eslint-plugin: [consistent-indexed-object-style] convert readonly index signature to readonly record (#​2798) (29428a4)
  • eslint-plugin: [consistent-type-imports] crash when using both default and namespace in one import (#​2778) (c816b84)
  • eslint-plugin: [explicit-module-boundary-types] ignore functions exported within typed object/array literals (#​2805) (73a63ee)
  • eslint-plugin: [no-use-before-define] allow class references if they're within a class decorator (#​2827) (050023a), closes #​2842
  • eslint-plugin: [triple-slash-reference] fix crash with external module reference (#​2788) (32b1b68)
  • scope-manager: fix assertion assignments not being marked as write references (#​2809) (fa68492), closes #​2804
  • typescript-estree: add default value for parserOptions.projectFolderIgnoreList and deduplicate resolved projects (#​2819) (bf904ec), closes #​2418 #​2814
Features

4.8.2 (2020-11-23)

Bug Fixes
  • eslint-plugin: [prefer-literal-enum-member] allow pure template literal strings (#​2786) (f3bf6a1)
  • typescript-estree: fix type-only regression for consumers not yet on TS 4.1 (#​2789) (50a46c6)

4.8.1 (2020-11-17)

Bug Fixes
  • eslint-plugin: [no-unnecessary-condition] false positive when array predicate returns unknown (#​2772) (111c244)
  • typescript-estree: parseWithNodeMaps returning empty maps (#​2773) (3e4a0ed)

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+43 -43

0 comment

2 changed files

renovate[bot]

pr closed time in 15 hours

PR opened very-geek/octane-sandbox

chore(renovate): update eslint related to v4.9.0

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@typescript-eslint/eslint-plugin 4.8.2 -> 4.9.0 age adoption passing confidence
@typescript-eslint/parser 4.8.2 -> 4.9.0 age adoption passing confidence

Release Notes

<details> <summary>typescript-eslint/typescript-eslint</summary>

v4.9.0

Compare Source

Bug Fixes
  • eslint-plugin: [consistent-indexed-object-style] convert readonly index signature to readonly record (#​2798) (29428a4)
  • eslint-plugin: [consistent-type-imports] crash when using both default and namespace in one import (#​2778) (c816b84)
  • eslint-plugin: [explicit-module-boundary-types] ignore functions exported within typed object/array literals (#​2805) (73a63ee)
  • eslint-plugin: [no-use-before-define] allow class references if they're within a class decorator (#​2827) (050023a), closes #​2842
  • eslint-plugin: [triple-slash-reference] fix crash with external module reference (#​2788) (32b1b68)
  • scope-manager: fix assertion assignments not being marked as write references (#​2809) (fa68492), closes #​2804
  • typescript-estree: add default value for parserOptions.projectFolderIgnoreList and deduplicate resolved projects (#​2819) (bf904ec), closes #​2418 #​2814
Features

4.8.2 (2020-11-23)

Bug Fixes
  • eslint-plugin: [prefer-literal-enum-member] allow pure template literal strings (#​2786) (f3bf6a1)
  • typescript-estree: fix type-only regression for consumers not yet on TS 4.1 (#​2789) (50a46c6)

4.8.1 (2020-11-17)

Bug Fixes
  • eslint-plugin: [no-unnecessary-condition] false positive when array predicate returns unknown (#​2772) (111c244)
  • typescript-estree: parseWithNodeMaps returning empty maps (#​2773) (3e4a0ed)

</details>


Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+43 -43

0 comment

2 changed files

pr created time in 15 hours

create barnchvery-geek/octane-sandbox

branch : renovate/eslint

created branch time in 15 hours

more