---
robots: noindex, nofollow
tags: pitch
---

# Fluent UI upgrades

### Problem

Immediately after TMP upgrade to FUI 0.47 was finished, new upgrade to FUI 0.50 was started.
That was in the beginning of July 2020. Target version of FUI changed during the process to 0.51.

There are 78 breaking changes between 0.47 and 0.51.

The upgrade PR is still alive in the beginning on October 2020 (3 months later) - they need to merge master, resolve conflicts and fix new problems every day - 1108 master commits in September 2020.
The PR has 41 required reviewers.

And TMP is still just a fraction of the app, new teams are ramping up.

Current TMP master is still on 0.47 (0.47.0 was released in March 2020). We need to release fixes in 47.x - we do it manually without any support by the CI, with screener results which are hard to reason about.

### Apetite

Make the upgrade proces managable at a cost of additional work/discipline on library side.
Be able to release fixes confidently.

### Solution

Bump react-northstar version to 1.0, start following semver.

Aim for **zero breaking changes**. When there is a breaking change, implement a new solution while keeping the deprecated code in place, provide consumers with a lint rule deprecating the old usage, codemod for upgrade. Remove the deprecated code in next version (it's consumer's responsibility to upgrade their code before that).

With our current API, theme styles are part of the "API contract" = any change to styles is potentially a breaking change. But we cannot apply the backwards-compatibility rules.

Support multiple versions in parallel. CI can build changes in release branches, Screener shows valid results which we understand.

Validate the proposal with TMP folks, make sure we understand their problems.

Setup a TMP CI build pipeline for master TMP - master FUI.

There is an additional price doing that - doing backward compatible changes is more difficult than just breaking the code. We need to implement a lint rule, codemod, cleanup the legacy code later. We need to cherry-pick fixes to multiple branches (which might eventually differ resulting in a need to implement fixes in different branches differently) - we need to learn this, follow the rules and set correct expectations for estimates.

Release FUI using CI instead of manual release?

### Risks (Rabbit holes)
v7 branch and repo/CI rework can collide with these changes.

### Out of scope (No-gos)
Not all work will be done in this month. But we should have agreed process and clear follow up tasks defined.