react-components versioning and release cycle

[miroslavstastny]

• switch to exact versions in dependencies
• will it work for unstable components? -> @layershifter
  • solution might be to still use ^versions and provide a resolutions generator
• manually triggered weekly/monthly release cycle?
• Write documentation about what partners can expect from beta: stability, whether there will be breaking changes, etc.

[JustSlone]

Topic to be covered in build v-team eta for update August 5th

[Hotell]

will it work for unstable components? -> @layershifter

• solution might be to still use ^versions and provide a resolutions generator

Can we get more context on this one folks ? 🙏 (RFC/DEMO)

[Hotell]

linking relevant docs from the sync:

• https://gist.github.com/Hotell/a1ace706ab87cb106fdc3039bba3f137
• convo:

PROPOSED: All vNext package.json deps should be pinned to specific versions (no carets, etc) including react-components suite package. This makes debugging and yarn resolutions manageable and predictable. Solves current issues with duplicate versions and bisecting hell when debugging.
Ultimate goal is to have determinate packages as much as possible in partner builds. We will confirm details of yarn resolutions to ensure we do what we can. Pinned versions is a best guess at the time of meeting, open to other solutions.

With current versioning those issues are easy to introduce and difficult to avoid and with lack of support time consuming to reveal.

Should we (re)add setVersion?
PROPOSED: will first try determinate versioning, if this is still an issue, we will reconsider. Issue here was side-effects mostly.
Keep the same version for all packages and always release everything in lockstep?

RESOLVED: We will release lock step packages in vNext. Partners shipping reusable components (HVCs) will use peerDeps (per standard practices).
Manual/nightly?
(note from Elizabeth: we previously implemented beachball features which could help with some of these things, so we may want to consider trying those features before totally switching systems for now, in the interest of time)

[layershifter]

will it work for unstable components? -> @layershifter

• solution might be to still use ^versions and provide a resolutions generator

Can we get more context on this one folks ? 🙏 (RFC/DEMO)

• Let's assume that we are using lock step versioning (all packages are bumped)
• Let's assume that we are strict versions (no carrets)

In my app I will consume @fluentui/[email protected]:

- @fluentui/[email protected]
  - @fluentui/[email protected]
  - @fluentui/[email protected]
  # 👆 dependencies are strict

In my app I want to use @fluentui/[email protected], this component is unstable and is not exported. That gives me:

- @fluentui/[email protected]
  - @fluentui/[email protected]
  - @fluentui/[email protected]

- @fluentui/[email protected]
  - @fluentui/[email protected]
  - @fluentui/[email protected]

As versions are strict, packages cannot be deduplicated even if they are according to semver are compatible. This leads to two problems:

• bundle size because of duplicates
• broken components as they will use different versions of React contexts and makeStyles(), sample demo on CodeSandbox

---

This could be solved via resolutions with Yarn to force these packages (@fluentui/react-make-styles, @fluentui/react-shared-contexts) to 9.3, but it creates another maintenance problem as everyone who bumps @fluentui/react-components should be aware of them.

[behowell]

8-19 update:

• @miroslavstastny and @levithomason to follow up to find an owner

[levithomason]

We're getting more requests to pin our internal versions during our pre-release tag phase so that compat is guaranteed for consumers.

[ling1726]

In the current state the steps required to release beta are:

• Run yarn nx workspace-generator version-bump --all --bumpType prerelease --prereleaseTag beta chore(version-bump): Generator to bump versions in the monorepo #19753
• Check in the package.json version changes
• Run a release in the v9 release pipeline chore: New pipeline for v9 release #19783

[ling1726]

Closing since the remainder of tasks have been moved to separate issues