[Discussion] Ideal Publishing Workflow

After our retrospective for this last cycle, it became clear that we should revisit our release/publish workflow (particularly for bugs). This issue is to discuss what our ideal workflow/publish flow would be. We can then take the outcome of this and create action items to deliver against over the next release cycle 👍

Real quick background information on our previous process and existing process 👇

Previous process

Previously, we made use of an amazing tool called semantic-release. This allowed us to automatically publish packages for each of our repos whenever we merged in a Pull Request. This tool would detect what version change should occur by looking at the underlying commits from the Pull Request, and then would generate a release accordingly.

However, as our release cadence (and our team) grew, we ended up publishing too many releases and teams couldn’t keep up. This left teams feeling distrustful over the stability of certain releases, and ultimately created a desire to pin carbon and not worry about keeping it up to date as each release jump could span multiple versions and subsequently carried risk for product teams

The as-is

As a result of the above, we may several adjustments to our release process. These include:

• Hotfixes, or bug fixes, are grouped as-needed instead of released as merged
• Minor releases are planned and delivered against, instead of being generated/dictated by commits into master
• Major releases follow a similar model to Minor
• We ship canary releases on every merge to master for the next minor release

Things that are painful right now:

• This process is incredibly manual, outside of canary
• Because the process is manually, collecting and documenting changelogs is harder
  • We want to rely on conventional commits for this, but it keeps saying things should be a major change when they shouldn’t

The to-be

This is where you come in! Drop down any ideas or suggestions to improve this process 🙏

[mattrosno]

Related to https://github.com/carbon-design-system/carbon/issues/2666, maybe we define how we use conventional commit types to reduce the number of feats that do minor version bumps?

And with that, whitelist conventional commit scopes to help with changelogs?

[joshblack]

@elizabethsjudd one thing that could help out with this is our canary builds. On merge to master we publish changed packages under the corresponding canary tag on NPM:

Although unfortunately this doesn’t help in that CI case that you mentioned 😞 Just wanted to bring it up though 👍