From 1401660094edf4b1a382bf0e3879ed0fcee47ea9 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Thu, 2 Nov 2023 15:38:57 -0400 Subject: [PATCH 01/10] initial --- text/0000-drop-safari-less-than-14.md | 92 +++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 text/0000-drop-safari-less-than-14.md diff --git a/text/0000-drop-safari-less-than-14.md b/text/0000-drop-safari-less-than-14.md new file mode 100644 index 0000000000..b7844691b0 --- /dev/null +++ b/text/0000-drop-safari-less-than-14.md @@ -0,0 +1,92 @@ +--- +stage: accepted +start-date: # In format YYYY-MM-DDT00:00:00.000Z +release-date: # In format YYYY-MM-DDT00:00:00.000Z +release-versions: +teams: # delete teams that aren't relevant + - cli + - data + - framework + - learning + - steering + - typescript +prs: + accepted: # Fill this in with the URL for the Proposal RFC PR +project-link: +suite: +--- + + + + +# Drop support for Safari < v14.1 + +## Summary + +Until v14.1, Safari doesn't support: +- private class fields: https://caniuse.com/mdn-javascript_classes_private_class_fields + +Other features in the ecosystem, + +class static initialization blocks: +- Safari 16.4: https://caniuse.com/mdn-javascript_classes_static_initialization_blocks + +This RFC is not concernd with static initialization blocks, as those can easily by transpiled without adding a a lot of code. + +## Motivation + +Private class field transpilation has a big impact on the kind of code emitted. We want to transpile as little as possible -- ideally nothing, and let app users decide if they need to transpile further. + +## Detailed design + +> This is the bulk of the RFC. + +> Explain the design in enough detail for somebody +familiar with the framework to understand, and for somebody familiar with the +implementation to implement. This should get into specifics and corner-cases, +and include examples of how the feature is used. Any new terminology should be +defined here. + +## How we teach this + +> What names and terminology work best for these concepts and why? How is this +idea best presented? As a continuation of existing Ember patterns, or as a +wholly new one? + +> Would the acceptance of this proposal mean the Ember guides must be +re-organized or altered? Does it change how Ember is taught to new users +at any level? + +> How should this feature be introduced and taught to existing Ember +users? + +## Drawbacks + +> Why should we *not* do this? Please consider the impact on teaching Ember, +on the integration of this feature with other existing and planned features, +on the impact of the API churn on existing apps, etc. + +> There are tradeoffs to choosing any path, please attempt to identify them here. + +## Alternatives + +> What other designs have been considered? What is the impact of not doing this? + +> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. + +## Unresolved questions + +> Optional, but suggested for first drafts. What parts of the design are still +TBD? From d51d2d461332bdf8adbba932a44a15c7adc6d0ef Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Thu, 2 Nov 2023 15:40:40 -0400 Subject: [PATCH 02/10] Update frontmatter --- ...afari-less-than-14.md => 0984-drop-safari-less-than-14.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-drop-safari-less-than-14.md => 0984-drop-safari-less-than-14.md} (95%) diff --git a/text/0000-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md similarity index 95% rename from text/0000-drop-safari-less-than-14.md rename to text/0984-drop-safari-less-than-14.md index b7844691b0..2aa48e9a8c 100644 --- a/text/0000-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -1,6 +1,6 @@ --- stage: accepted -start-date: # In format YYYY-MM-DDT00:00:00.000Z +start-date: 2023-11-02T15:40:00.000Z release-date: # In format YYYY-MM-DDT00:00:00.000Z release-versions: teams: # delete teams that aren't relevant @@ -11,7 +11,7 @@ teams: # delete teams that aren't relevant - steering - typescript prs: - accepted: # Fill this in with the URL for the Proposal RFC PR + accepted: https://github.com/emberjs/rfcs/pull/984 project-link: suite: --- From cbfe861e42a63978398afc2fa041b2cbe3ffa712 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Thu, 2 Nov 2023 16:38:00 -0400 Subject: [PATCH 03/10] specify --- text/0984-drop-safari-less-than-14.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index 2aa48e9a8c..ebd1132a73 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -51,6 +51,9 @@ Private class field transpilation has a big impact on the kind of code emitted. ## Detailed design +Ember v6 Will not support Safari < v14.1 + + > This is the bulk of the RFC. > Explain the design in enough detail for somebody From 76611b6cba6048748331ac0c43aa48d78cfe244f Mon Sep 17 00:00:00 2001 From: Aaron Chambers Date: Fri, 3 Nov 2023 14:42:11 +0000 Subject: [PATCH 04/10] Apply suggestions from code review Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com> --- text/0984-drop-safari-less-than-14.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index ebd1132a73..82fbdaa451 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -43,15 +43,15 @@ Other features in the ecosystem, class static initialization blocks: - Safari 16.4: https://caniuse.com/mdn-javascript_classes_static_initialization_blocks -This RFC is not concernd with static initialization blocks, as those can easily by transpiled without adding a a lot of code. +This RFC is not concerned with static initialization blocks, as those can easily be transpiled without adding a a lot of code. ## Motivation -Private class field transpilation has a big impact on the kind of code emitted. We want to transpile as little as possible -- ideally nothing, and let app users decide if they need to transpile further. +Private class fields transpilation has a big impact on the kind of code emitted. We want to transpile as little as possible -- ideally nothing, and let app users decide if they need to transpile further. ## Detailed design -Ember v6 Will not support Safari < v14.1 +Ember v6 will not support Safari < v14.1 > This is the bulk of the RFC. From 53c4701fbfd3a29053456fe8d6e8b31e5d2bd1c3 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Fri, 2 Feb 2024 11:10:20 -0500 Subject: [PATCH 05/10] Update safari to be evergreen --- text/0984-drop-safari-less-than-14.md | 291 +++++++++++++++++++++++--- 1 file changed, 257 insertions(+), 34 deletions(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index 82fbdaa451..c3efd4c348 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -31,19 +31,11 @@ project-link: Leave as is suite: Leave as is --> -# Drop support for Safari < v14.1 +# Treat Safari as an Evergreen Browser ## Summary -Until v14.1, Safari doesn't support: -- private class fields: https://caniuse.com/mdn-javascript_classes_private_class_fields - -Other features in the ecosystem, - -class static initialization blocks: -- Safari 16.4: https://caniuse.com/mdn-javascript_classes_static_initialization_blocks - -This RFC is not concerned with static initialization blocks, as those can easily be transpiled without adding a a lot of code. +Safari's release cadence has increased as well as relevant-device compatibilty. This RFC proposes an amendment to the [browser support](https://emberjs.com/browser-support/) policy to treat Safari the same as Chrome and FireFox for Desktop and Mobile devices. ## Motivation @@ -54,42 +46,273 @@ Private class fields transpilation has a big impact on the kind of code emitted. Ember v6 will not support Safari < v14.1 -> This is the bulk of the RFC. +## How we teach this + +### A new browser support policy -> Explain the design in enough detail for somebody -familiar with the framework to understand, and for somebody familiar with the -implementation to implement. This should get into specifics and corner-cases, -and include examples of how the feature is used. Any new terminology should be -defined here. +Diff: +- remove non-evergreen section +- place Safari under Evergreen Desktop and Evergreen Mobile +- actual numbers subject to change as time passes, this is an example -## How we teach this +```diff +{{page-title "Browser Support"}} +
+
+

Ember.js Browser Support Policy

+ + ++

Ember 6.0.0

++ ++

++ In Ember 6.0.0, the framework supports the following major browsers: ++

++ ++
    ++ ++
    Desktop
    ++
      ++
    • Google Chrome >= 103
      • ++
    • Mozilla Firefox >= 102
      • ++
    • Microsoft Edge >= 110
      • ++
    • Safari >= 16.4
      • ++
    ++     ++ ++
    Mobile
    ++
      ++
    • Google Chrome >= 112
      • ++
    • Mozilla Firefox >= 110
      • ++
    • Safari >= 16.4
      • ++
    ++     ++ ++
    Testing
    ++
      ++
    • Google Chrome
      • ++
    • Mozilla Firefox
      • ++
    ++     ++
+ +

Ember 5.0.0

+ +

+ In Ember 5.0.0, the framework supports the following major browsers: +

+ +
    + +
    Desktop
    +
      +
    • Google Chrome >= 103
      • +
    • Mozilla Firefox >= 102
      • +
    • Microsoft Edge >= 110
      • +
    • Safari >= 12
      • +
    +     + +
    Mobile
    +
      +
    • Google Chrome >= 112
      • +
    • Mozilla Firefox >= 110
      • +
    • Safari >= 12
      • +
    +     + +
    Testing
    +
      +
    • Google Chrome
      • +
    • Mozilla Firefox
      • +
    +     +
+ +

Ember 4.0.0

+ +

+ In Ember 4.0.0, the framework supports the following major browsers: +

+ +
    + +
    Desktop
    +
      +
    • Google Chrome >= 92
      • +
    • Mozilla Firefox >= 91
      • +
    • Microsoft Edge >= 93
      • +
    • Safari >= 12
      • +
    +     + +
    Mobile
    +
      +
    • Chrome Android >= 96
      • +
    • Firefox Android >= 94
      • +
    • Safari >= 12
      • +
    +     + +
    Testing
    +
      +
    • Google Chrome
      • +
    • Mozilla Firefox
      • +
    +     +
+ +

Ember 3.0.0

-> What names and terminology work best for these concepts and why? How is this -idea best presented? As a continuation of existing Ember patterns, or as a -wholly new one? +

+ Ember currently targets Internet Explorer 11 as a baseline for support. This means that generally all modern and relatively recent browsers will work with Ember, since browsers are backwards compatible by design. Ember runs tests against the latest desktop versions of the following browsers: +

-> Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? +
+
+
+
    +
  • Google Chrome
    • +
  • Mozilla Firefox
    • +
  • Microsoft Edge
    • +
  • Internet Explorer 11
    • +
  • Safari
    • +
+
+
+
-> How should this feature be introduced and taught to existing Ember -users? +

+ Other browsers may work with Ember.js, but are not explicitly supported. If you + would like to add support for a new browser, please submit an RFC or RFC issue for discussion! +

+ + +

+ We determine support on a browser-by-browser basis. Browsers are categorized as + either evergreen or non-evergreen. The categorization is as follows: +

+ +

Evergreen

+ +
    + +
    Desktop
    +
      +
    • Google Chrome
      • +
    • Mozilla Firefox
      • +
    • Microsoft Edge
      • ++
    • Safari
      • +
    +     + +
    Mobile
    +
      +
    • Google Chrome
      • +
    • Mozilla Firefox
      • ++
    • Safari
      • +
    +     + +
    Testing
    +
      +
    • Google Chrome
      • +
    • Mozilla Firefox
      • +
    +     +
+ +-

Non-evergreen

+- +-
+-
    +- +-
    Desktop
    +-
      +-
    • Safari
      • +-
    +-     +- +-
    Mobile
    +-
      +-
    • Safari
      • +-
    +-     +-
+-
+ +

+ For evergreen browsers, the minimum version of the browser that we support is + determined at the time of every minor release, following this formula: +

+ +
+
+
+

Whichever browser version is greater/more recent out of:

+ +
    +
  1. + The lowest/least recent version that fulfills any one of these properties: +
      +
    • It is the latest version of the browser.
      • +
    • It is the latest LTS/extended support version of the browser (such as Firefox ESR).
      • +
    • It has at least 0.25% of global marketshare usage across mobile and + desktop, based on statcounter.
      • +
    +
    2. +
  2. + The minimum version supported in the previous release +
    3. +
+
+
+
+ +

+ To simplify, the supported version either moves forward or stays the same for + each release based on overall usage and LTS/current release versions. +

+ +

+ For non-evergreen browsers, support is locked at a specific major version, and + we support all major versions above that version. ++ However, all supported browsers are considered ever green. +

+ +-
+-
    +- +-
    Desktop
    +-
      +-
    • Safari: 12
      • +-
    +-     +- +-
    Mobile
    +-
      +-
    • Safari: 12
      • +-
    +-     +-
+-
+ + Within a version of a browser, we only support the most recent patch release. +
+
+``` ## Drawbacks -> Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. +More calculations for us to do when determining browser support for a particular version of ember. +(based on the algorithm described in -> There are tradeoffs to choosing any path, please attempt to identify them here. +> Whichever browser version is greater/more recent out of: + +) -## Alternatives -> What other designs have been considered? What is the impact of not doing this? +## Alternatives -> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. ## Unresolved questions -> Optional, but suggested for first drafts. What parts of the design are still -TBD? From 39b51106b5a37acffa0381f1b44b822f377aefcd Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Fri, 2 Feb 2024 11:21:30 -0500 Subject: [PATCH 06/10] Add link to old RFC --- text/0984-drop-safari-less-than-14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index c3efd4c348..4d74e21a57 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -35,7 +35,7 @@ suite: Leave as is ## Summary -Safari's release cadence has increased as well as relevant-device compatibilty. This RFC proposes an amendment to the [browser support](https://emberjs.com/browser-support/) policy to treat Safari the same as Chrome and FireFox for Desktop and Mobile devices. +Safari's release cadence has increased as well as relevant-device compatibilty. This RFC proposes an amendment to the [browser support](https://emberjs.com/browser-support/) policy (introduced in [RFC#685](https://rfcs.emberjs.com/id/0685-new-browser-support-policy)) to treat Safari the same as Chrome and FireFox for Desktop and Mobile devices. ## Motivation From 3eeec820691e9f45756d09bcb9f006f4b0fbe6d6 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Fri, 2 Feb 2024 14:35:56 -0500 Subject: [PATCH 07/10] Update 0984-drop-safari-less-than-14.md --- text/0984-drop-safari-less-than-14.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index 4d74e21a57..d40e9e69fc 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -241,14 +241,19 @@ Diff: -

- For evergreen browsers, the minimum version of the browser that we support is +- For evergreen browsers, the minimum version of the browser that we support is ++ For evergreen browsers, the minimum version of the browser that we support can be determined at the time of every minor release, following this formula:

-

Whichever browser version is greater/more recent out of:

+-

Whichever browser version is greater/more recent out of:

++

++ Whichever browser version is greater/more recent out of the following, ++ given that the owning entity (e.g.: Apple, Google, Mozilla) still supports the version ++

  1. From 82cbd166b84c56425888d40023ce8e60e8f0a854 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 5 Feb 2024 14:47:18 -0500 Subject: [PATCH 08/10] Update text/0984-drop-safari-less-than-14.md Co-authored-by: Katie Gengler --- text/0984-drop-safari-less-than-14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index d40e9e69fc..432afae2fd 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -43,7 +43,7 @@ Private class fields transpilation has a big impact on the kind of code emitted. ## Detailed design -Ember v6 will not support Safari < v14.1 +Ember v6 will support Safari based on usage statistics, the same as other browsers we support. ## How we teach this From 9ef506c3ac84b116cf9bcd6d7e9704a31076df74 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 5 Feb 2024 16:21:47 -0800 Subject: [PATCH 09/10] Update text/0984-drop-safari-less-than-14.md Co-authored-by: Katie Gengler --- text/0984-drop-safari-less-than-14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-drop-safari-less-than-14.md index 432afae2fd..874a1e2cfd 100644 --- a/text/0984-drop-safari-less-than-14.md +++ b/text/0984-drop-safari-less-than-14.md @@ -39,7 +39,7 @@ Safari's release cadence has increased as well as relevant-device compatibilty. ## Motivation -Private class fields transpilation has a big impact on the kind of code emitted. We want to transpile as little as possible -- ideally nothing, and let app users decide if they need to transpile further. +Treating Safari differently from other browsers is no longer necessary due to changes in release cadence. Only being able to adjust Safari support with an RFC and at major versions is unnecessary overhead. ## Detailed design From 573b0fa5730e3cdb6479d2d6dac9d8fa01fc2d6f Mon Sep 17 00:00:00 2001 From: Aaron Chambers Date: Wed, 7 Feb 2024 15:14:36 +0000 Subject: [PATCH 10/10] Rename 0984-drop-safari-less-than-14.md to 0984-update-browser-support-policy.md --- ...fari-less-than-14.md => 0984-update-browser-support-policy.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0984-drop-safari-less-than-14.md => 0984-update-browser-support-policy.md} (100%) diff --git a/text/0984-drop-safari-less-than-14.md b/text/0984-update-browser-support-policy.md similarity index 100% rename from text/0984-drop-safari-less-than-14.md rename to text/0984-update-browser-support-policy.md