• We need to be aware of a breaking change prior to doing a release
  • We have a way to label a PR as “breaking” pre-merge and post-merge
    • pre-merge: engineer can mark as commit as breaking with feat!: or fix!:
      • the label release-breaking is automatically added to the PR
    • post-merge: engineer or PM can label a PR as release-breaking
• When a release is created, it should be impossible to create a patch release if there were PRs with breaking changes
  • Any breaking changes are in a separate section in the changelog
  • We modify our changelog generation script to look up corresponding PRs, check for a breaking label, and sort them accordingly

  # old workflow
  git tag -m "release v0.0.0" v0.0.0
  git push origin v0.0.0
  
  # new workflow
  ./scripts/release.sh patch [-n|--dry-run]
  error: found breaking change
  promote to minor

Things to consider

• Documentation on how to create a release.
• Removing the workflow on tag to prevent "legacy releases"