Make deprecation workflow built in #1009
Conversation
|
|
||
| ## How we teach this | ||
|
|
||
| We'd want to add a new section in the guides under [`Application Concerns`](https://guides.emberjs.com/release/applications/) that talks about deprecations, how and how to work through those deprecations. |
There was a problem hiding this comment.
How and how to?
Perhaps "when and how to"?
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
|
The Question:
It's possible we can do the first, and then the second, but the addon isn't very big (it's just one file, basically) |
NullVoxPopuli
added
S-Exploring
|
This is something I'm surprised has t happened sooner. From what I've seen, you kinda had to be 'in the know' to use deprecation-workflow, and it wasn't clear that it was the recommended upgrade approach, at least for those who weren't around during its early days. +1 for baking it in. Or at least having an ember-cli command that installs it. |
|
RFC Review (1) are in favour of this. |
|
|
||
| loadInitializers(App, config.modulePrefix); | ||
| ``` | ||
| this conditional import is now easily customizable for folks in their apps, so they could opt to _not_ strip deprecation messages in production, and see where deprecated code is being hit by users (reported via Sentry, BugSnag, or some other reporting tool) -- which may be handy for folks who have a less-than-perfect test suite (tests being the only current way to automatically detect where deprecated code lives). |
There was a problem hiding this comment.
deprecate calls from ember in production are stripped as part of Ember's build, not the project's, so there would be no way to keep them in production, right now
| let matchKey = options && key === options.id ? 'matchId' : 'matchMessage'; | ||
|
|
||
| self.deprecationWorkflow.deprecationLog.messages[key] = | ||
| ' { handler: "silence", ' + matchKey + ': ' + JSON.stringify(key) + ' }'; |
There was a problem hiding this comment.
Whether in deprecation-workflow or in a new implementation, I think we should also capture options.url and options.for. The other options.since I feel less strongly about but may be nice.
|
|
||
| ## Alternatives | ||
|
|
||
| Have `ember-cli-deprecation-workflow` installed by default, (and) transferring `ember-cli-deprecation-workflow` to the emberjs org. |
There was a problem hiding this comment.
I'm in favor of this option. While it may not be much code, adding the addon is a quick path.
Co-authored-by: Katie Gengler <katie@kmg.io>
Propose making deprecation-workflow built in.
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage), followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP