-
-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advance RFC #0726 "DOM Element descriptor interface for test helpers"
to Stage Released
#1004
Conversation
@bendemboski please comment here when the releases are out for this. Thanks. |
Any updates on this @bendemboski ? |
|
Discussion at tooling meeting today was hashing out the implementation strategy to unblock the qunit-dom feature. We have a consensus plan on a pluggable implementation in qunit-dom that meets everybody's needs. |
I see that a release of qunit-dom went out, @bendemboski what remains to be released? |
@ef4 nothing! I've updated the checklist above, however I'd like to hold off on declaring victory until I can update the test app in |
@ef4 I just release v1.0 of For the last checklist item above -- ( |
Thanks, I edited the release versions directly into this PR. |
Advance #726 to the Released Stage
Rendered
Summary
This pull request is advancing the RFC to the Released Stage.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Recommended Stage.
Released Stage Summary
The work is published. If it is codebase-related work, it is in a stable version of the relevant package(s). If there are any critical deviations from the original RFC, they are briefly noted at the top of the RFC.
If the work for an RFC is spread across multiple releases of Ember or other packages, the RFC is considered to be in the Released stage when all features are available in stable releases and those packages and versions are noted in the RFC frontmatter.
Ember's RFC process can be used for process and work plans that are not about code. Some examples include Roadmap RFCs, changes to the RFC process itself, and changes to learning resources. When such an RFC is a candidate for Released, the work should be shipped as described, and the result should presented to the team with the intent of gathering feedback about whether anything is missing. If there is agreement that the work is complete, the RFC may be marked "Released" and a date is provided instead of a version.
An RFC is moved into "Released" when the above is verified by consensus of the relevant team(s) via a PR to update the stage.
Checklist to move to Released