diff --git a/.github/PULL_REQUEST_TEMPLATE/advance-to-ready-for-release.md b/.github/PULL_REQUEST_TEMPLATE/advance-to-ready-for-release.md index 390d88e2c3..e206fb9145 100644 --- a/.github/PULL_REQUEST_TEMPLATE/advance-to-ready-for-release.md +++ b/.github/PULL_REQUEST_TEMPLATE/advance-to-ready-for-release.md @@ -31,6 +31,8 @@ Each Ember core team will be requested as a reviewer on the PR to move into this - [ ] Implementation is complete according to plan outlined in the RFC, with any adjustments noted in the RFC - [ ] Any necessary learning materials have been updated - [ ] The Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature. This is the go/no go decision for any feature flags, but the flags should only be turned on when moving to Released. +- [ ] The feature may not yet have support by the entire ecosystem (e.g. IDEs, addons, Ember Inspector, Engines, Lint Rules, Blueprints, etc), but it does not unintentionally break any existing functionality in those areas. +- [ ] The Interactive Tutorial is not broken by this feature. - [ ] Criteria for moving to the Recommended Stage has been filled out - [ ] This PR has been converted from a draft to a regular PR and the `Final Comment Period` label has been added to start the FCP - [ ] Each [team](https://github.com/emberjs/rfcs#relevant-teams) has been added as a reviewer to the PR at the start of the FCP. Reviews are not required by the end of the FCP. This is a notification step. diff --git a/.github/PULL_REQUEST_TEMPLATE/advance-to-recommended.md b/.github/PULL_REQUEST_TEMPLATE/advance-to-recommended.md index 7f958b1507..bf0daf89b9 100644 --- a/.github/PULL_REQUEST_TEMPLATE/advance-to-recommended.md +++ b/.github/PULL_REQUEST_TEMPLATE/advance-to-recommended.md @@ -37,13 +37,21 @@ An FCP is required to enter this stage. Multiple RFCs may be moved as a batch in ## Checklist to move to Recommended -- [ ] Any criteria for "Recommended" for this proposal that were established in the Ready For Release stage have been met -- [ ] If appropriate, the feature is integrated into the tutorial and the guides prose. API documentation is polished and updates are carried through to other areas of API docs that may not directly pertain to the feature. -- [ ] If the proposal replaces an existing feature, the addon ecosystem has largely updated to work with both old and new features. -- [ ] If the proposal updates or replaces an existing feature, high-quality codemods are available -- [ ] If needed, Ember debugging tools as well as popular IDE support have been updated to support the feature. -- [ ] If the feature is part of a suite of features that were designed to work together for best ergonomics, the other features are also ready to be "Recommended". -- [ ] This PR has been converted from a draft to a regular PR and the `Final Comment Period` label has been added to start the FCP +- [ ] **Criteria specific to this feature:** Any additional criteria for "Recommended" for this proposal that were established in the Ready For Release stage have been met. +- [ ] **Tutorial:** If appropriate, the feature is integrated into the tutorial. +- [ ] **Guides:** If appropriate, the feature is integrated into the guides prose. +- [ ] **API Docs:** API documentation is polished and updates are carried through to other areas of API docs that may not directly pertain to the feature. +- [ ] **Addon Ecosystem:** If the proposal replaces an existing feature, the addon ecosystem has largely updated to work with both old and new features. +- [ ] **Codemods:** If the proposal updates or replaces an existing feature, high-quality codemods are available. +- [ ] **Debugging Tools:** If needed, Ember debugging tools (e.g. Ember Inspector, Deprecation Workflow) have been updated to support the feature. +- [ ] **IDE Support:** If needed, popular IDE support has been updated to support the feature. +- [ ] **Engines, SSR:** If needed, ecosystem feature such as Ember Engines, SSR support have been updated to support the feature. +- [ ] **Blueprints:** Blueprints have been updated to support the feature and to reflect the new best practices implied by this feature. +- [ ] **Linting:** Lint rules have been updated or added or removed to support the feature and to reflect the new best practices implied by this feature. +- [ ] **Deprecations:** If this feature implies that other features are no longer best practice, RFCs have been created to deprecate those features. +- [ ] **Blog Post:** Consider if a blog post should be written to introduce this feature to the community. +- [ ] **Feature Suite:** If the feature is part of a suite of features that were designed to work together for best ergonomics, the other features are also ready to be "Recommended". +- [ ] **FCP to Recommended:** This PR has been converted from a draft to a regular PR and the `Final Comment Period` label has been added to start the FCP. ## Criteria for moving to Recommended (required) diff --git a/0000-template.md b/0000-template.md index 73e1cf60f1..ddfaa7c758 100644 --- a/0000-template.md +++ b/0000-template.md @@ -30,7 +30,8 @@ project-link: Leave as is suite: Leave as is --> -# +<-- Replace "RFC title" with the title of your RFC --> +# RFC title ## Summary @@ -49,7 +50,17 @@ outcome? 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. +defined here. + +> Please keep in mind any implications within the Ember ecosystem, such as: +> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed +> - Features that are replaced or made obsolete by this feature and should eventually be deprecated +> - Ember Inspector and debuggability +> - Server-side Rendering +> - Ember Engines +> - The Addon Ecosystem +> - IDE Support +> - Blueprints that should be added or modified ## How we teach this @@ -64,6 +75,8 @@ at any level? > How should this feature be introduced and taught to existing Ember users? +> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. + ## Drawbacks > Why should we *not* do this? Please consider the impact on teaching Ember, diff --git a/deprecation-template.md b/deprecation-template.md index d86f0ae8d6..fcf280ae85 100644 --- a/deprecation-template.md +++ b/deprecation-template.md @@ -28,7 +28,8 @@ prs: project-link: Leave as is --> -# +<-- Replace "RFC title" with the title of your RFC --> +# RFC Title ## Summary @@ -47,6 +48,19 @@ Describe it in enough detail for someone who uses the deprecated functionality to understand, for someone to write the deprecation guide, and for someone familiar with the implementation to implement. +> It can be helpful to write the deprecation guide as part of this section. Published deprecation +> guides can be found at https://deprecations.emberjs.com/. + +> Please keep in mind any implications within the Ember ecosystem, such as: +> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed +> - Features that are replaced or made obsolete by this feature and should eventually be deprecated +> - Ember Inspector and debuggability +> - Server-side Rendering +> - Ember Engines +> - The Addon Ecosystem +> - IDE Support +> - Blueprints that should be added or modified + ## How We Teach This > Would the acceptance of this proposal mean the Ember guides must be @@ -58,6 +72,8 @@ related to this feature? How should this deprecation be introduced and explained to existing Ember users? +> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. + ## Drawbacks > Why should we *not* do this? Please consider the impact on teaching Ember, diff --git a/text/0659-unique-id-helper.md b/text/0659-unique-id-helper.md index 9c4db39d6b..ca333ec20f 100644 --- a/text/0659-unique-id-helper.md +++ b/text/0659-unique-id-helper.md @@ -1,14 +1,14 @@ --- -stage: released # FIXME: This may be recommended +stage: recommended start-date: 2020-08-25T00:00:00.000Z release-date: 2022-05-02T00:00:00.000Z release-versions: ember-source: v4.4.0 - teams: - framework prs: - accepted: https://github.com/emberjs/rfcs/pull/659 + accepted: 'https://github.com/emberjs/rfcs/pull/659' + recommended: 'https://github.com/emberjs/rfcs/pull/865' project-link: --- diff --git a/text/0726-dom-element-descriptor-interface.md b/text/0726-dom-element-descriptor-interface.md index 805dfbe7af..b0b467515f 100644 --- a/text/0726-dom-element-descriptor-interface.md +++ b/text/0726-dom-element-descriptor-interface.md @@ -1,17 +1,18 @@ --- -stage: accepted +stage: ready-for-release start-date: 2021-03-13T00:42:02.085Z -release-date: # In format YYYY-MM-DDT00:00:00.000Z +release-date: release-versions: -teams: # delete teams that aren't relevant +teams: - cli - framework - learning - typescript prs: - accepted: https://github.com/emberjs/rfcs/pull/726 + accepted: 'https://github.com/emberjs/rfcs/pull/726' + ready-for-release: 'https://github.com/emberjs/rfcs/pull/992' project-link: -suite: +suite: --- # DOM Element descriptor interface for test helpers diff --git a/text/0774-implicit-record-route-loading.md b/text/0774-implicit-record-route-loading.md index 467ac2d7b3..4a22118c0f 100644 --- a/text/0774-implicit-record-route-loading.md +++ b/text/0774-implicit-record-route-loading.md @@ -1,14 +1,17 @@ --- -stage: released +stage: recommended start-date: 2021-11-14T00:00:00.000Z -release-date: +release-date: 2024-03-04T00:00:00.00Z release-versions: + ember-source: v5.7.0 + ember-cli: v5.7.0 teams: - framework prs: accepted: 'https://github.com/emberjs/rfcs/pull/774' ready-for-release: 'https://github.com/emberjs/rfcs/pull/900' released: 'https://github.com/emberjs/rfcs/pull/955' + recommended: 'https://github.com/emberjs/rfcs/pull/970' --- # Deprecate Implicit Record Loading in Routes @@ -46,9 +49,9 @@ By removing this behaviour, we will encourage developers to explicitly define wh We will issue a deprecation to [`findModel`](https://github.com/emberjs/ember.js/blob/017b11e2f58880869a5b8c647bf7f3199fc07f26/packages/%40ember/-internals/routing/lib/system/route.ts#L1376) notifying the user that if they want to continue this behaviour of attempting to fetch a resource implicitly, they should try and replicate with their own explicitly defined `model` hook. -In addition, we will include an [optional feature](https://github.com/emberjs/ember-optional-features) to disable this feature and clear the deprecation. +In addition, we will include an [optional feature](https://github.com/emberjs/ember-optional-features) to disable this feature and clear the deprecation. This optional feature will be enabled in the blueprint because we want new apps to get this behaviour by default. -In v6.0.0, we will remove `findModel` and logic to determine arguments for this method. This will not remove returning the `transition` context when no `model` hook is defined. +In v6.0.0, we will remove `findModel` and logic to determine arguments for this method. This will not remove returning the `transition` context when no `model` hook is defined. The optional feature will also be removed. ## How we teach this diff --git a/text/0776-typescript-blueprints.md b/text/0776-typescript-blueprints.md index 1daef59b51..60ac50b269 100644 --- a/text/0776-typescript-blueprints.md +++ b/text/0776-typescript-blueprints.md @@ -1,5 +1,5 @@ --- -stage: released +stage: recommended start-date: 2021-11-11T00:00:00.000Z release-date: 2022-12-08T00:00:00.000Z release-versions: @@ -12,6 +12,7 @@ prs: accepted: 'https://github.com/emberjs/rfcs/pull/776' ready-for-release: 'https://github.com/emberjs/rfcs/pull/873' released: 'https://github.com/emberjs/rfcs/pull/911' + recommended: 'https://github.com/emberjs/rfcs/pull/912' project-link: --- diff --git a/text/0811-element-modifiers.md b/text/0811-element-modifiers.md index 045eed0d5b..3feac9cf67 100644 --- a/text/0811-element-modifiers.md +++ b/text/0811-element-modifiers.md @@ -1,5 +1,5 @@ --- -stage: released +stage: recommended start-date: 2022-03-29T00:00:00.000Z release-date: 2023-03-03T00:00:00.000Z release-versions: @@ -11,6 +11,7 @@ prs: accepted: 'https://github.com/emberjs/rfcs/pull/811' ready-for-release: 'https://github.com/emberjs/rfcs/pull/885' released: 'https://github.com/emberjs/rfcs/pull/928' + recommended: 'https://github.com/emberjs/rfcs/pull/934' project-link: --- diff --git a/text/0918-deprecate-travis-ci-support.md b/text/0918-deprecate-travis-ci-support.md index 4770a27fad..0e1b69f241 100644 --- a/text/0918-deprecate-travis-ci-support.md +++ b/text/0918-deprecate-travis-ci-support.md @@ -1,14 +1,17 @@ --- -stage: ready-for-release +stage: recommended start-date: 2023-03-25T00:00:00.000Z -release-date: +release-date: 2023-12-11T00:00:00.000Z release-versions: + ember-cli: 5.5.0 teams: - cli - learning prs: accepted: 'https://github.com/emberjs/rfcs/pull/918' ready-for-release: 'https://github.com/emberjs/rfcs/pull/954' + released: 'https://github.com/emberjs/rfcs/pull/978' + recommended: 'https://github.com/emberjs/rfcs/pull/994' project-link: --- diff --git a/text/0984-update-browser-support-policy.md b/text/0984-update-browser-support-policy.md new file mode 100644 index 0000000000..874a1e2cfd --- /dev/null +++ b/text/0984-update-browser-support-policy.md @@ -0,0 +1,323 @@ +--- +stage: accepted +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 + - cli + - data + - framework + - learning + - steering + - typescript +prs: + accepted: https://github.com/emberjs/rfcs/pull/984 +project-link: +suite: +--- + + + + +# Treat Safari as an Evergreen Browser + +## 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 (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 + +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 + +Ember v6 will support Safari based on usage statistics, the same as other browsers we support. + + +## How we teach this + +### A new browser support policy + +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 + +```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

+ +

+ 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: +

+ +
+
+
+
    +
  • Google Chrome
  • +
  • Mozilla Firefox
  • +
  • Microsoft Edge
  • +
  • Internet Explorer 11
  • +
  • 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! +

+ + +

+ 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 ++ 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 the following, ++ given that the owning entity (e.g.: Apple, Google, Mozilla) still supports the version ++

+ +
    +
  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. +
  3. + The minimum version supported in the previous release +
  4. +
+
+
+
+ +

+ 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 + +More calculations for us to do when determining browser support for a particular version of ember. +(based on the algorithm described in + +> Whichever browser version is greater/more recent out of: + +) + + +## Alternatives + + +## Unresolved questions + diff --git a/text/0995-deprecate-non-colocated-components.md b/text/0995-deprecate-non-colocated-components.md new file mode 100644 index 0000000000..0de131f283 --- /dev/null +++ b/text/0995-deprecate-non-colocated-components.md @@ -0,0 +1,247 @@ +--- +stage: accepted +start-date: 2023-12-15T00:00:00.000Z +release-date: +release-versions: +teams: # delete teams that aren't relevant + - cli + - framework + - learning + - typescript +prs: + accepted: https://github.com/emberjs/rfcs/pull/995 +project-link: +--- + + + +# Deprecate non-co-located components. + +## Summary + +Deprecates +- classic component layout +- pods component layout + + +Once this deprecation is implemented, only the following will be allowed: +- co-located components +- gjs / gts components + +## Motivation + +These older component layouts force build tooling to keep a lot of resolution rules around, and makes it hard for codemods and other community tooling to effectively work across folks' projects. + + +## Transition Path + +There are two types of paths to migrate off the old layouts +- use a currently supported multi-file layout (keeping separate `js`, `ts`, and `hbs` files) +- migrate the component entirely to the latest component format, `gjs`, `gts`, (aka `