Problem
During Fluent UI React v9 RC we have discovered some deprecations and breaking changes we want to give serious consideration. There is a high bar for making any breaking changes as we move from RC to Stable v9 and any breaks we do make must be done in a coordinated fashion that eases any upgrade pain for consumers and is simple to communicate. Ideally this will make upgrading simpler for the core development team as well.
We need to collect all potential breaking changes to be made as part of RC and have a plan for evaluating and implementing them.
Appetite
6 weeks.
Solution
All proposed breaking changes will be linked to this issue so we can easily see the scope of proposed change. As part of moving from RC to Stable we will assemble a "ship room" to consider each proposal and either move forward with it or discard it.
The workflow for all proposed changes is:
- Review the change and decide whether or not to move forward with it.
- Some considerations in no particular order
- What is Partner appetite/need for this upgrade?
- Can it be automated via something like codemods or is it a relatively simple find-n-replace?
- Can the break be worked around?
- What are the benefits of making the break vs the costs of not making it? For example, are we using an OSS library that is no longer supported?
- Is there a dramatic performance benefit of making the change?
- ...please add other considerations, keeping in mind this isn't an exhaustive list...
- If we will not make the change
- Note the decision and discard the proposal
- If we will make the change
- Write up docs explaining how to migrate from the old API to the new one. Write any tooling like codemods to assist in the upgrade.
- Communicate the change with Partners
- Make the change in a backwards compatible manner and ship this version so Partners can piecemeal upgrade their applications.
- Remove the old API and ship this version once all Partners have upgraded.
- Ensure you have availability to help Partners through the upgrade process
Risks (Rabbit holes)
- Discussing proposed changes exhaustively. We should aim to quickly make yes or no decisions about which changes to make.
- Spending lots of time writing codemods
Out of scope (No-gos)
- Significant reworking/refactoring of APIs. This is not an opportunity to fundamentally rethink features but clean up little inconsistencies and set Partners and the development team up for success in the long term.
Problem
During Fluent UI React v9 RC we have discovered some deprecations and breaking changes we want to give serious consideration. There is a high bar for making any breaking changes as we move from RC to Stable v9 and any breaks we do make must be done in a coordinated fashion that eases any upgrade pain for consumers and is simple to communicate. Ideally this will make upgrading simpler for the core development team as well.
We need to collect all potential breaking changes to be made as part of RC and have a plan for evaluating and implementing them.
Appetite
6 weeks.
Solution
All proposed breaking changes will be linked to this issue so we can easily see the scope of proposed change. As part of moving from RC to Stable we will assemble a "ship room" to consider each proposal and either move forward with it or discard it.
The workflow for all proposed changes is:
Risks (Rabbit holes)
Out of scope (No-gos)