|
| 1 | +--- |
| 2 | +stage: accepted |
| 3 | +start-date: |
| 4 | +release-date: |
| 5 | +release-versions: |
| 6 | +teams: # delete teams that aren't relevant |
| 7 | + - cli |
| 8 | + - data |
| 9 | + - framework |
| 10 | + - learning |
| 11 | + - steering |
| 12 | + - typescript |
| 13 | +prs: |
| 14 | + accepted: # update this to the PR that you propose your RFC in |
| 15 | +project-link: |
| 16 | +--- |
| 17 | + |
| 18 | +<!--- |
| 19 | +Directions for above: |
| 20 | +
|
| 21 | +stage: Leave as is |
| 22 | +start-date: Fill in with today's date, 2032-12-01T00:00:00.000Z |
| 23 | +release-date: Leave as is |
| 24 | +release-versions: Leave as is |
| 25 | +teams: Include only the [team(s)](README.md#relevant-teams) for which this RFC applies |
| 26 | +prs: |
| 27 | + accepted: Fill this in with the URL for the Proposal RFC PR |
| 28 | +project-link: Leave as is |
| 29 | +--> |
| 30 | + |
| 31 | +# Deprecating the `Evented` Mixin |
| 32 | + |
| 33 | +## Summary |
| 34 | + |
| 35 | +> One paragraph explanation of the deprecation. |
| 36 | +
|
| 37 | +## Motivation |
| 38 | + |
| 39 | +> Why are we doing this? What are the problems with the deprecated feature? |
| 40 | +What is the replacement functionality? |
| 41 | + |
| 42 | +## Transition Path |
| 43 | + |
| 44 | +> This is the bulk of the RFC. Explain the use-cases that deprecated functionality |
| 45 | +covers, and for each use-case, describe the transition path. |
| 46 | +Describe it in enough detail for someone who uses the deprecated functionality |
| 47 | +to understand, for someone to write the deprecation guide, and for someone |
| 48 | +familiar with the implementation to implement. |
| 49 | + |
| 50 | +> It can be helpful to write the deprecation guide as part of this section. Published deprecation |
| 51 | +> guides can be found at https://deprecations.emberjs.com/. |
| 52 | +
|
| 53 | +> Please keep in mind any implications within the Ember ecosystem, such as: |
| 54 | +> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed |
| 55 | +> - Features that are replaced or made obsolete by this feature and should eventually be deprecated |
| 56 | +> - Ember Inspector and debuggability |
| 57 | +> - Server-side Rendering |
| 58 | +> - Ember Engines |
| 59 | +> - The Addon Ecosystem |
| 60 | +> - IDE Support |
| 61 | +> - Blueprints that should be added or modified |
| 62 | +
|
| 63 | +## How We Teach This |
| 64 | + |
| 65 | +> Would the acceptance of this proposal mean the Ember guides must be |
| 66 | +re-organized or altered? Does it change how Ember is taught to new users |
| 67 | +at any level? |
| 68 | +Does it mean we need to put effort into highlighting the replacement |
| 69 | +functionality more? What should we do about documentation, in the guides |
| 70 | +related to this feature? |
| 71 | +How should this deprecation be introduced and explained to existing Ember |
| 72 | +users? |
| 73 | + |
| 74 | +> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. |
| 75 | +
|
| 76 | +## Drawbacks |
| 77 | + |
| 78 | +> Why should we *not* do this? Please consider the impact on teaching Ember, |
| 79 | +on the integration of this feature with other existing and planned features, |
| 80 | +on the impact of the API churn on existing apps, etc. |
| 81 | +There are tradeoffs to choosing any path, please attempt to identify them here. |
| 82 | + |
| 83 | +## Alternatives |
| 84 | + |
| 85 | +> What other designs have been considered? What is the impact of not doing this? |
| 86 | +
|
| 87 | +## Unresolved questions |
| 88 | + |
| 89 | +> Optional, but suggested for first drafts. What parts of the design are still |
| 90 | +TBD? |
0 commit comments