52 строки
1.6 KiB
Markdown
52 строки
1.6 KiB
Markdown
- Start Date: (fill me in with today's date, YYYY-MM-DD)
|
|
- RFC PR: (leave this empty)
|
|
- ReactiveUI Issue: (leave this empty)
|
|
|
|
# Summary
|
|
|
|
One paragraph explanation of the deprecation.
|
|
|
|
# Motivation
|
|
|
|
Why are we doing this? What are the problems with the deprecated feature?
|
|
What is the replacement functionality?
|
|
|
|
# Transition Path
|
|
|
|
This is the bulk of the RFC. Explain the use-cases that deprecated functionality
|
|
covers, and for each use-case, describe the transition path.
|
|
|
|
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.
|
|
|
|
# How We Teach This
|
|
|
|
Would the acceptance of this proposal mean the ReactiveUI guides must be
|
|
re-organized or altered? Does it change how ReactiveUI is taught to new users
|
|
at any level?
|
|
|
|
Does it mean we need to put effort into highlighting the replacement
|
|
functionality more? What should we do about documentation, in the guides
|
|
related to this feature?
|
|
|
|
How should this deprecation be introduced and explained to existing ReactiveUI
|
|
users?
|
|
|
|
# Drawbacks
|
|
|
|
Why should we *not* do this? Please consider the impact on teaching ReactiveUI,
|
|
on the integration of this feature with other existing and planned features,
|
|
on the impact of the API churn on existing apps, etc.
|
|
|
|
There are tradeoffs to choosing any path, please attempt to identify them here.
|
|
|
|
# Alternatives
|
|
|
|
What other designs have been considered? What is the impact of not doing this?
|
|
|
|
# Unresolved questions
|
|
|
|
Optional, but suggested for first drafts. What parts of the design are still
|
|
TBD?
|