v9 release strategy

[Hotell]

Story 🧚‍♀️

Current behaviour

We trigger v9 release pipeline manually.

Why?:

• to mitigate releases overload and spamming npm registry
• to be able troubleshoot/identify which version introduced particular issue or regression

This will trigger following workflow:

• create production builds of v9 packages
• run beachball
  • bumps package versions based on existing change files
  • generates/updates Changelogs
• publish packages to npm registry
• fix version mismatches created by beachball via automation ( TBA )

New behaviour (proposal)

Release approach

Going forward we wanna adhere to/pick one of the following workflows:

1. Manual release (anytime)

Releases are triggered manually as of today with improved tooling so there are no issues and manuall follow-ups needed.

• releases are triggered manually
• triggered as necessary

Implementation Effort: Medium

Why this approach:

• get fixes to partners ASAP
• mitigate releases overload and spamming npm registry
• better tracking/troubleshooting possible regression that might happen in UI library

How will I get Bug fixes:

• immediately after fix is merged and PoC triggers release pipeline

If there is "high severity" issue, once there is capacity it will be immediately worked on. After PR with fix is merged, we will trigger release immediately.

This will result in:

• patch release (if there are only patches present since last release)
• minor release (if there is at least one feature/minor change since last release)

2. Manual release (milestone aligned)

• releases are triggered manually
• triggered by milestones end ( strictly follow planned items for particular milestone).

Implementation Effort: Medium

Why this approach:

• aligment of our release cadence with milestones to follow standard OSS roadmap practices + Public relations announcement
• mitigate releases overload and spamming npm registry
• better tracking/troubleshooting possible regression that might happen in UI library

How will I get Bug fixes:

• with next planned release / milestone end

If there is "high severity" issue, it will be acoomodated based on priority and current milestone. If it has higher severity than issues and features already planned for active milestone, it will be added to this milestone and when fixed released within upcoming release window.

This will result in:

• patch release (only on milestone end if there are only patches present since last release)
• minor release (only on milestone end if there is at least one feature/minor change since last release)

3. Semi-manual release

• minor releases are triggered manually with milestone alignment
• releases are triggered automatically for fixes

Implementation Effort: High

Why this approach:

• get fixes to partners ASAP
• aligment of our release cadence with milestones to follow standard OSS roadmap practices + Public relations announcement
• mitigate releases overload and spamming npm registry
• better tracking/troubleshooting possible regression that might happen in UI library

How will I get Bug fixes:

• immediately after fix is merged or via next planned release (milestone end), whichever is earlier

This will result in:

• patch release (daily automated releases that would accommodate patches only)
• minor release (only on milestone end and if there is at least one feature/minor change since last milestone release)

Bug fixes approach

As we strictly follow semver we don't plan to back-port fixes to previous minor versions.

Scenario Example 1 (only patches):

• customer A uses v9.1.0
• fluent team merges various PR's that are marked with type "patch" ( will trigger patch bump when releasing )
• customer A (on v9.1.0) reports and issue
• in the meantime we release -> as there are only type: patch commits fluent bumps to v9.1.1
• we fix the issue of customer A, merge PR
• we release -> the fix is type:patch so fluent bumps to v9.1.2

Scenario Example 2 (patches+minors):

• customer A uses v9.1.0
• fluent team merges various PR's that are marked with at least 1 type "minor" ( will trigger minor bump when releasing )
• customer A (on v9.1.0) reports and issue
• in the meantime we release -> as there was at least 1 type: minor commit, fluent bumps to v9.2.0
• we fix the issue of customer A, merge PR
• we release -> the fix is type:patch so fluent bumps to v9.2.1
• customer A , bumps to v9.2.1 where he will have his issue fixed. Also this version will contain new features - that's expressed by 2 a minor number
• 💡 NOTE: we wont back-port this fix to 9.1.0 release thus we wont release this as 9.1.1

Related Issues and blockers

• Integrate dependency mismatch generator to release pipeline #24207
• beachball tries to release based on a peer dependency bump #23929
• fluent v8/v9 releases are not published to github releases #24053
• Beachball disallowed changetypes breaks nightly releases #25117

[ling1726]

The hybrid automated/manual release feels ambitious for beachball, where we already add a bunch of hacks to coexist with the release of v8 in isolation.

We should either add the necessary changes directly in beachball v2 or go custom. Our in-repo workarounds for beachball are getting unsustainable

[paulgildea]

From a customer perspective, they are mostly interested in the timing of the releases. So I really like the idea of aligning to our milestones and then on demand for hotfixes.

So messaging could be: "We release every month, but if you need a hotfix we can do a one-off, but if you can wait until the end that would be great... :-)"

[MLoughry]

The faster from checkin to release, the better. Of the three options, only # 1 comes close to that. Ideally, daily releases or even continuous delivery would be better.

[levithomason]

I would agree with @MLoughry above.

[Hotell]

Updates:

Since Q1 we are using approach no 1 with great success - Manual release (anytime)

We are closely monitoring the cadence and type of releases. Based on those data we might introduce automation in future.

I'll close this epic for now.

Cheers