From 8d7a13d21bea5efdcf18cd417cb88bd9eda46bc2 Mon Sep 17 00:00:00 2001 From: Gaurav Munjal Date: Fri, 22 May 2020 05:42:36 -0400 Subject: [PATCH 01/11] New browser support policy --- text/0000-new-browser-support-policy.md | 67 +++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 text/0000-new-browser-support-policy.md diff --git a/text/0000-new-browser-support-policy.md b/text/0000-new-browser-support-policy.md new file mode 100644 index 0000000000..168ae2f832 --- /dev/null +++ b/text/0000-new-browser-support-policy.md @@ -0,0 +1,67 @@ +- Start Date: 2020-05-21 +- Relevant Team(s): All +- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name) +- Tracking: (leave this empty) + +# New Browser Support Policy + +## Summary + +> In dropping support for IE11 at some point in the future, we will need a new +browswer support policy. This is the proposed policy. + +## Motivation + +> It should be clear which browsers are supported by Ember.js + +## Detailed policy + +- Desktop + + 1. Google Chrome + + - The current and previous stable releases are supported + + 2. Mozilla Firefox + + - The current and previous rapid releases and the latest [ESR](https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel) are supported + + 3. MS Edge + + - The current and previous stable releases are supported. + + 4. Mac Safari + + - The versions coming with the current and previous releases of MacOS are supported, as well as versions of Mac Safari available with updates to the current release. + +- Mobile + + 1. Google Chrome + + - The versions coming with all versions of Android released in the past 18 months are supported, as well as the current and most stable releases available via update. + + 2. iOS Safari + + - The versions coming with all versions of iOS released in the past 36 months are supported. + + 3. Android + + - The versions released with all versions of Android released in the past 18 months are supported. + +All browsers not listed here may work but are not explicitly supported. + +## How we teach this + +> A blog post explaining the policy with a link to this RFC will be posted. + +## Drawbacks + +- See discussions on this RFC + +## Alternatives + +> See discussions on this RFC + +## Unresolved questions + +> Should a version of non Chromium MS Edge be supported, and if so for how long? From 5e1f62da78ce821f1486d997479c26d279657e6e Mon Sep 17 00:00:00 2001 From: Gaurav Munjal Date: Fri, 22 May 2020 05:44:32 -0400 Subject: [PATCH 02/11] fix typo --- text/0000-new-browser-support-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-new-browser-support-policy.md b/text/0000-new-browser-support-policy.md index 168ae2f832..ace87faf92 100644 --- a/text/0000-new-browser-support-policy.md +++ b/text/0000-new-browser-support-policy.md @@ -8,7 +8,7 @@ ## Summary > In dropping support for IE11 at some point in the future, we will need a new -browswer support policy. This is the proposed policy. +browser support policy. This is the proposed policy. ## Motivation From 47d08b578693925220a978ed1e680e3d119dcc79 Mon Sep 17 00:00:00 2001 From: Gaurav Munjal Date: Fri, 22 May 2020 15:02:57 -0400 Subject: [PATCH 03/11] first revision from comments --- ...pport-policy.md => 0630-new-browser-support-policy.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename text/{0000-new-browser-support-policy.md => 0630-new-browser-support-policy.md} (80%) diff --git a/text/0000-new-browser-support-policy.md b/text/0630-new-browser-support-policy.md similarity index 80% rename from text/0000-new-browser-support-policy.md rename to text/0630-new-browser-support-policy.md index ace87faf92..35aefee8da 100644 --- a/text/0000-new-browser-support-policy.md +++ b/text/0630-new-browser-support-policy.md @@ -1,6 +1,6 @@ - Start Date: 2020-05-21 - Relevant Team(s): All -- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name) +- RFC PR: https://github.com/emberjs/rfcs/pull/630 - Tracking: (leave this empty) # New Browser Support Policy @@ -24,7 +24,7 @@ browser support policy. This is the proposed policy. 2. Mozilla Firefox - - The current and previous rapid releases and the latest [ESR](https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel) are supported + - The current and previous rapid releases and any [ESR](https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel) versions currently supported by Mozilla are supported 3. MS Edge @@ -38,7 +38,7 @@ browser support policy. This is the proposed policy. 1. Google Chrome - - The versions coming with all versions of Android released in the past 18 months are supported, as well as the current and most stable releases available via update. + - The versions coming with all versions of Android released in the past 36 months are supported, as well as the current and most stable releases available via update. 2. iOS Safari @@ -46,7 +46,7 @@ browser support policy. This is the proposed policy. 3. Android - - The versions released with all versions of Android released in the past 18 months are supported. + - The versions released with all versions of Android released in the past 36 months are supported. All browsers not listed here may work but are not explicitly supported. From 94a20c31f63d6ec3b7a537bec759f894a76aeec7 Mon Sep 17 00:00:00 2001 From: Gaurav Munjal Date: Tue, 26 May 2020 12:31:01 -0400 Subject: [PATCH 04/11] second revision --- text/0630-new-browser-support-policy.md | 52 ++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 6 deletions(-) diff --git a/text/0630-new-browser-support-policy.md b/text/0630-new-browser-support-policy.md index 35aefee8da..e13d4b687f 100644 --- a/text/0630-new-browser-support-policy.md +++ b/text/0630-new-browser-support-policy.md @@ -8,13 +8,42 @@ ## Summary > In dropping support for IE11 at some point in the future, we will need a new -browser support policy. This is the proposed policy. +browser support policy. This is the proposed policy for that point in the future. +By properly documenting our browser support policy, +we increase our flexibility and provide explicit clarification of intended support. ## Motivation -> It should be clear which browsers are supported by Ember.js +> It should be clear which browsers are supported by Ember.js, +to eliminate any confusion and decrease the number of decisions +we're required to make about any feature (existing or new). -## Detailed policy +## 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 + +This policy drops support for a major browser, and therefore can only be +implemented with a major version bump. - Desktop @@ -52,15 +81,26 @@ All browsers not listed here may work but are not explicitly supported. ## How we teach this -> A blog post explaining the policy with a link to this RFC will be posted. +- 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 -- See discussions on this RFC +- The proposed policy adds significant testing work to make up for +the dropping of IE11 support. This is more than made up for by clarity. +In practice our users need to support many of these browsers +anyway, and without Internet Explorer 11 compatibility requirement +it is likely that older mobile browsers will become the new limits +that prevent us from taking advantage of new features. ## Alternatives -> See discussions on this RFC +- Keep things as they are. +- Document the existing policy but do not change it. +- Support fewer browsers, for a shorter amount of time. +- Support more browsers, for a longer amount of time. ## Unresolved questions From 09059a09105c123ac94de6c2f47a8d0dae53a763 Mon Sep 17 00:00:00 2001 From: Gaurav Munjal Date: Tue, 9 Jun 2020 15:34:39 -0400 Subject: [PATCH 05/11] add review cadence to unresolved questions --- text/0630-new-browser-support-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0630-new-browser-support-policy.md b/text/0630-new-browser-support-policy.md index e13d4b687f..0d248107f1 100644 --- a/text/0630-new-browser-support-policy.md +++ b/text/0630-new-browser-support-policy.md @@ -104,4 +104,5 @@ that prevent us from taking advantage of new features. ## Unresolved questions -> Should a version of non Chromium MS Edge be supported, and if so for how long? +- Should a version of non Chromium MS Edge be supported, and if so for how long? +- How often should this policy be reviewed? From 76bf7eaf70ceccb0bf4043c4ae92b302e525075e Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Wed, 30 Sep 2020 14:42:18 -0700 Subject: [PATCH 06/11] Updates based on feedback --- text/0000-new-browser-support-policy.md | 286 ++++++++++++++++++++++++ text/0630-new-browser-support-policy.md | 108 --------- 2 files changed, 286 insertions(+), 108 deletions(-) create mode 100644 text/0000-new-browser-support-policy.md delete mode 100644 text/0630-new-browser-support-policy.md diff --git a/text/0000-new-browser-support-policy.md b/text/0000-new-browser-support-policy.md new file mode 100644 index 0000000000..5f427c706f --- /dev/null +++ b/text/0000-new-browser-support-policy.md @@ -0,0 +1,286 @@ +- Start Date: 2020-11-28 +- Relevant Team(s): All +- RFC PR: +- Tracking: (leave this empty) + +# 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 either of the following criteria: + +1. It is the latest version of the browser. +2. 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 + +- Keep things as they are. +- Document the existing policy but do not change it. +- Support fewer browsers, for a shorter amount of time. +- Support more browsers, for a longer amount of time. diff --git a/text/0630-new-browser-support-policy.md b/text/0630-new-browser-support-policy.md deleted file mode 100644 index 0d248107f1..0000000000 --- a/text/0630-new-browser-support-policy.md +++ /dev/null @@ -1,108 +0,0 @@ -- Start Date: 2020-05-21 -- Relevant Team(s): All -- RFC PR: https://github.com/emberjs/rfcs/pull/630 -- Tracking: (leave this empty) - -# New Browser Support Policy - -## Summary - -> In dropping support for IE11 at some point in the future, we will need a new -browser support policy. This is the proposed policy for that point in the future. -By properly documenting our browser support policy, -we increase our flexibility and provide explicit clarification of intended support. - -## Motivation - -> It should be clear which browsers are supported by Ember.js, -to eliminate any confusion and decrease the number of decisions -we're required to make about any feature (existing or new). - -## 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 - -This policy drops support for a major browser, and therefore can only be -implemented with a major version bump. - -- Desktop - - 1. Google Chrome - - - The current and previous stable releases are supported - - 2. Mozilla Firefox - - - The current and previous rapid releases and any [ESR](https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel) versions currently supported by Mozilla are supported - - 3. MS Edge - - - The current and previous stable releases are supported. - - 4. Mac Safari - - - The versions coming with the current and previous releases of MacOS are supported, as well as versions of Mac Safari available with updates to the current release. - -- Mobile - - 1. Google Chrome - - - The versions coming with all versions of Android released in the past 36 months are supported, as well as the current and most stable releases available via update. - - 2. iOS Safari - - - The versions coming with all versions of iOS released in the past 36 months are supported. - - 3. Android - - - The versions released with all versions of Android released in the past 36 months are supported. - -All browsers not listed here may work but are not explicitly supported. - -## 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 adds significant testing work to make up for -the dropping of IE11 support. This is more than made up for by clarity. -In practice our users need to support many of these browsers -anyway, and without Internet Explorer 11 compatibility requirement -it is likely that older mobile browsers will become the new limits -that prevent us from taking advantage of new features. - -## Alternatives - -- Keep things as they are. -- Document the existing policy but do not change it. -- Support fewer browsers, for a shorter amount of time. -- Support more browsers, for a longer amount of time. - -## Unresolved questions - -- Should a version of non Chromium MS Edge be supported, and if so for how long? -- How often should this policy be reviewed? From 7c96c4df5e2b99731b655bec4345ecd9c84061ad Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Sat, 28 Nov 2020 10:19:12 -0800 Subject: [PATCH 07/11] rename based on PR --- ...olicy.md => 0685-new-browser-support-policy.md} | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) rename text/{0000-new-browser-support-policy.md => 0685-new-browser-support-policy.md} (98%) diff --git a/text/0000-new-browser-support-policy.md b/text/0685-new-browser-support-policy.md similarity index 98% rename from text/0000-new-browser-support-policy.md rename to text/0685-new-browser-support-policy.md index 5f427c706f..431ab0aee5 100644 --- a/text/0000-new-browser-support-policy.md +++ b/text/0685-new-browser-support-policy.md @@ -1,7 +1,13 @@ -- Start Date: 2020-11-28 -- Relevant Team(s): All -- RFC PR: -- Tracking: (leave this empty) +--- +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 From 216a67af9aa1ef8b8a953a8175ab6f074217e1da Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Mon, 30 Nov 2020 09:40:53 -0800 Subject: [PATCH 08/11] account for LTS/ESR evergreen browsers --- text/0685-new-browser-support-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0685-new-browser-support-policy.md b/text/0685-new-browser-support-policy.md index 431ab0aee5..9e0b20f38a 100644 --- a/text/0685-new-browser-support-policy.md +++ b/text/0685-new-browser-support-policy.md @@ -131,10 +131,11 @@ matrix for Ember users. ### Evergreen browsers Ember and Ember Data will support **all** versions of evergreen browsers which -meet either of the following criteria: +meet any of the following criteria: 1. It is the latest version of the browser. -2. It has at least **0.25%** marketshare usage, based on +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 From c572cc7b3627095a1f2780c89921d9b15e4aec46 Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Thu, 3 Dec 2020 11:16:30 -0800 Subject: [PATCH 09/11] address feedback --- text/0685-new-browser-support-policy.md | 281 +++++++++++++++++------- 1 file changed, 199 insertions(+), 82 deletions(-) diff --git a/text/0685-new-browser-support-policy.md b/text/0685-new-browser-support-policy.md index 9e0b20f38a..b9233f3bd2 100644 --- a/text/0685-new-browser-support-policy.md +++ b/text/0685-new-browser-support-policy.md @@ -61,113 +61,110 @@ 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 +## Proposed policy -The existing policy is listed here for documentation purposes. +In the new support policy, Ember will support the following browsers: - Desktop + 1. Google Chrome + 2. Mozilla Firefox + 3. Microsoft Edge + 4. Safari +- Mobile + 1. Google Chrome + 2. Mozilla Firefox + 3. Safari +- Testing + 1. Headless Chrome + 2. Headless Safari - 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. +Any browser which is not listed here may work, but is not explicitly supported. -- Mobile +In addition, these browsers have been categorized into _evergreen_ and +_non-evergreen_ browsers, which have different support policies. This categories +have been chose arbitrarily, based on the current state of browsers and their +support policies. - 1. All +- Evergreen + - Desktop + 1. Google Chrome + 2. Chromium + 3. Mozilla Firefox + 4. Microsoft Edge + - Mobile + 1. Google Chrome + 2. Mozilla Firefox + - Testing + 1. Headless Chrome + 2. Headless Safari - - All mobile browsers may work but are not explicitly supported. +- Non-evergreen + - Desktop + 1. Safari + - Mobile + 1. Safari -Any browsers not listed here may work but are not explicitly supported. +This categorization will _not_ change without an additional RFC, even if the +browsers themselves make significant changes to their own release process or +support system. -## Proposed policy +#### Heuristics for browser categorization -In the new support policy, we define two categories of browsers: +As mentioned above, the evergreen and non-evergreen categorization is ultimately +arbitrary. However, there were some heuristics which were used to categorize the +supported browsers at the time this RFC was made: -1. **Evergreen browsers**, which are browsers that: +1. **Evergreen browsers** are browsers that: - * Support using the latest version on all supported platforms (e.g. you can + - 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. + - Automatically update whenever a new version is available. -2. **Non-evergreen browsers**, which are any browsers which do not meet the +2. **Non-evergreen browsers** 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: +For a given Ember and Ember Data minor release, the minimum major version +supported for a given browser is determined using the following formula. -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/). +- Whichever browser version is greater/more recent out of: + 1. The lowest/least recent version that fulfills any one of these properties + - It is the latest version of the browser. + - It is the latest LTS/extended support version of the browser (such as Firefox ESR). + - It has at least **0.25%** of global marketshare usage across mobile and + desktop, based on [statcounter](https://gs.statcounter.com/). + 2. The minimum version supported in the previous release -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. +Within a major version of a browser, the latest patch release is the only +release that is supported. -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. +This policy has the following attributes: -_Within_ a minor version, support works as follows: +- It allows us to generally support the most recent browser versions, which + are typically used for some time before everyone upgrades +- It allows us to support browser versions that become temporary "speedbumps" + that take longer for users to update, such as the last non-Chromium version of + MS Edge. +- It prevents backsliding, once a version is no longer supported, it never + becomes supported again. -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. +Above all else, this policy is easy to communicate - for every minor release, we +calculate the minimum supported version, and then communicate that we support +all versions >= that version. -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. +It is important to note that this policy means that each minor release _may_ +drop support for some major versions of evergreen browsers. ### Non-evergreen browsers -Ember and Ember Data will support the following versions of non-evergreen -browsers: +Ember and Ember Data will support all major versions greater than or equal to +the following version for non-evergreen browsers: - Desktop - Safari: 14 @@ -178,9 +175,8 @@ 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. +Within a major version of a browser, the latest patch release is the only +release that is supported. #### Note on the versions chosen @@ -262,15 +258,134 @@ _require_ a major version of Ember to implement. ## Implementation +In order to support this policy while keeping all of our tooling on the same +page, Ember.js itself will add automation to calculate the current minimum +supported version of browsers on its main branch, and publish them in an +accessible format. Each time we branch a release, these versions will stop +updating, so they will effectively be locked in. + +These versions will be used for a variety of use cases, such as generating +documentation and release blog posts (see below), and generating the default +`config/targets.js` for new Ember apps and addons. + +### Implementation timeline + 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 +This will be an ongoing process, since the minimum browser versions supported +change over time. The most important thing here is that users can easily +determine whether or not a given version of a browser is supported for a given +Ember release. + +The following are the ways we will communicate this: + +- For the release blog post for a minor version, we'll include a table which has + the list of every supported browser, along with the minimum supported major + version of that browser for the release +- On the [releases page](https://emberjs.com/releases) of the Ember.js website, + for each of the listed releases, we will include a table of the supported + versions major browsers for that release. +- The browser support on the releases page for the Stable and LTS branches will + be linked in the Ember.js README. + +This documentation will be supported by the minimum supported versions that are +published in the Ember.js package (see above), which will allow them to be +mostly automated. The supported browser table could look like the following +(generated using today's usage stats): + +### Supported Browsers + +#### Desktop + +| Chrome | Edge | Firefox | Safari | +| ------ | ---- | -------- | ------ | +| 83 | 18 | 78 (ESR) | 14 | + +#### Mobile + +| Chrome | Firefox | Safari | +| ------ | ------- | ------ | +| 87 | 83 | 14 | + +#### Headless + +| Chrome | Firefox | +| ------ | -------- | +| 87 | 78 (ESR) | + +### "How we determine support" page + +In addition, the technical details of the support policy should be documented on +the Ember website, in a less prominent position (e.g. a link from the supported +versions table titled "how do we determine browser support?"). This could use +the following text: + +Ember supports the following major browsers: + +- Desktop + 1. Google Chrome + 2. Mozilla Firefox + 3. Microsoft Edge + 4. Safari +- Mobile + 1. Google Chrome + 2. Mozilla Firefox + 3. Safari +- Testing + 1. Headless Chrome + 2. Headless Safari + +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](https://github.com/emberjs/rfcs)! + +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 + 1. Google Chrome + 2. Chromium + 3. Mozilla Firefox + 4. Microsoft Edge + - Mobile + 1. Google Chrome + 2. Mozilla Firefox + - Testing + 1. Headless Chrome + 2. Headless Safari + +- Non-evergreen + - Desktop + 1. Safari + - Mobile + 1. 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](https://gs.statcounter.com/). + 2. The minimum version supported in the previous release + +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: + +- Desktop + - Safari: 14 +- Mobile + - Safari: 14 + +Within a version of a browser, we only support the most recent patch release. ## Drawbacks @@ -291,3 +406,5 @@ implemented with a major version bump. - Document the existing policy but do not change it. - Support fewer browsers, for a shorter amount of time. - Support more browsers, for a longer amount of time. +- Drop IE11 but not add more definition to support (keeping it as a case by case + determination by the core teams) From 333911bd11a20c32985b87a6a23502b2c4b89acd Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Thu, 3 Dec 2020 11:25:27 -0800 Subject: [PATCH 10/11] add note on semver --- text/0685-new-browser-support-policy.md | 26 +++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/text/0685-new-browser-support-policy.md b/text/0685-new-browser-support-policy.md index b9233f3bd2..cb28d020dd 100644 --- a/text/0685-new-browser-support-policy.md +++ b/text/0685-new-browser-support-policy.md @@ -206,7 +206,7 @@ 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 +### What support means This policy governs two major aspects of Ember and Ember Data: @@ -234,7 +234,7 @@ available to fix any browser specific issues that occur in: For the previous LTS release, only security bugfixes will be supported, following the existing LTS policy. -## Future changes to the 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 @@ -256,6 +256,28 @@ implemented. Future RFCs that amend this policy to _remove_ support for a browser will _require_ a major version of Ember to implement. +### Impact on SemVer + +While this policy does result in us dropping support for versions of browsers +with each minor release, this RFC proposes that this should not have an impact +on our SemVer policy. SemVer is a communication mechanism, which is used to +communicate to users when impactful changes occur, and what those changes are in +broad categories: breaking, new features, bugfixes. + +While dropping support for an evergreen browser version could be considered +breaking in the strictest technical sense, it generally is not considered one +because of the usage patterns that these browsers have in the first place. Their +users are automatically opted into updating every time they boot the browser, +which means in almost all cases users update quickly and efficiently. In fact, +it is often considered a _security issue_ if users are _not_ using the most +recent version of an evergreen browser. + +As such, the fact is that in most cases, if a bug is somehow reported on an +older version of an unsupported browser, then the fix is usually to tell the +user to update the browser version, not to patch the application or framework +for that browser version. In practice, this is how Ember has operated for years, +and this policy only formalizes this process. + ## Implementation In order to support this policy while keeping all of our tooling on the same From c9bbc894a6f2ecdd0a2db414fb754e884bad9cc2 Mon Sep 17 00:00:00 2001 From: Chris Garrett Date: Fri, 4 Dec 2020 16:45:40 -0800 Subject: [PATCH 11/11] tweaks for feedback --- text/0685-new-browser-support-policy.md | 51 +++++++++---------------- 1 file changed, 18 insertions(+), 33 deletions(-) diff --git a/text/0685-new-browser-support-policy.md b/text/0685-new-browser-support-policy.md index cb28d020dd..0d928c8b47 100644 --- a/text/0685-new-browser-support-policy.md +++ b/text/0685-new-browser-support-policy.md @@ -96,7 +96,7 @@ support policies. 2. Mozilla Firefox - Testing 1. Headless Chrome - 2. Headless Safari + 2. Headless Firefox - Non-evergreen - Desktop @@ -167,9 +167,9 @@ Ember and Ember Data will support all major versions greater than or equal to the following version for non-evergreen browsers: - Desktop - - Safari: 14 + - Safari: 12 - Mobile - - Safari: 14 + - Safari: 12 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 @@ -180,31 +180,9 @@ release that is 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. +iOS Safari 12 has a usage of ~1.5% globally as of the writing of this RFC. Given +this, and the fact that newer versions of Safari do not introduce any major +features, 12 seems like an acceptable cutoff at this time. ### What support means @@ -290,6 +268,12 @@ These versions will be used for a variety of use cases, such as generating documentation and release blog posts (see below), and generating the default `config/targets.js` for new Ember apps and addons. +### Deprecation + +We will add a deprecation to Ember CLI that shows when users have any +unsupported browser in there `targets.json`, along with a guide for updating to +modern targets. + ### Implementation timeline This policy drops support for a major browser, and therefore can only be @@ -306,7 +290,8 @@ The following are the ways we will communicate this: - For the release blog post for a minor version, we'll include a table which has the list of every supported browser, along with the minimum supported major - version of that browser for the release + version of that browser for the release. We will also include the underlying + engine version. - On the [releases page](https://emberjs.com/releases) of the Ember.js website, for each of the listed releases, we will include a table of the supported versions major browsers for that release. @@ -324,13 +309,13 @@ mostly automated. The supported browser table could look like the following | Chrome | Edge | Firefox | Safari | | ------ | ---- | -------- | ------ | -| 83 | 18 | 78 (ESR) | 14 | +| 83 | 18 | 78 (ESR) | 12 | #### Mobile | Chrome | Firefox | Safari | | ------ | ------- | ------ | -| 87 | 83 | 14 | +| 87 | 83 | 12 | #### Headless @@ -403,9 +388,9 @@ For non-evergreen browsers, support is locked at a specific major version, and we support all major versions above that version: - Desktop - - Safari: 14 + - Safari: 12 - Mobile - - Safari: 14 + - Safari: 12 Within a version of a browser, we only support the most recent patch release.