Skip to content

Instantly share code, notes, and snippets.

@mikekistler

mikekistler/breaking-change-labels.md

Last active February 15, 2024 23:49
Show Gist options
  • Save mikekistler/5a35e1ca7d69a52b4e55c25d805fe5d1 to your computer and use it in GitHub Desktop.
Save mikekistler/5a35e1ca7d69a52b4e55c25d805fe5d1 to your computer and use it in GitHub Desktop.
Download ZIP
Breaking Change Labels
Raw
breaking-change-labels.md

Proposal for new Breaking Change Labels

Update of proposal from this comment.

Breaking Changes

BreakingChangeReviewRequired

  • Added by automation when it detects a breaking change from a previous GA API version
  • Blocks merge until a "BreakingChange-Approved*" label is applied

BreakingChange-Approved-Benign

  • The changes to the REST API definition are not breaking at the REST API level and have at most minor impact to generated SDKs, so the change is allowed.
  • Should only be applied by Breaking Change reviewer

BreakingChange-Approved-BugFix

  • The changes to the REST API definition are correcting the definition to accurately describe the service behavior.
  • This could be self-selected

BreakingChange-Approved-UserImpact

  • The PR describes actual breaking changes to the service.
  • Should only be applied by Breaking Change reviewer
  • This is the only case that triggers customer notifications, a 3 yr migration period (possibly shorter), etc.
  • Within this set we may want to distinguish changes for security or legal compliance, which may be granted a shorter migration period.

BreakingChange-Approved-Previously

  • The PR contains breaking changes that were previously reviewed and approved.
  • Should only be applied by Breaking Change reviewer (maybe open this up in the future)
  • It is desirable but not mandatory to add a link the previously approved PR in a comment on this PR.

Versioning

VersioningReviewRequired

  • Added by automation when it detects changes to an existing API version in a production branch, which violates the Azure versioning policy.
  • Blocks merge until a "Versioning-Approved*" label is applied

Versioning-Approved-Benign

  • Changes to the REST API definition are not breaking at the REST API level and have at most minor impact to generated SDKs, so the change is allowed.
  • Should only be applied by Breaking Change reviewer

Versioning-Approved-BugFix

  • The changes to the REST API definition are correcting the definition to accurately describe the service behavior.
  • This could be self-selected

Versioning-Approved-PrivatePreview

  • The API Version that triggered the review is in private preview, and non-breaking changes are permitted in the same API version during private preview.
  • This could be self-selected.

Versioning-Approved-NotReleased

  • The API Version that triggered the review has not yet been released, despite having been merged to a production branch.
  • This could be self-selected in the private repo only.

Versioning-Approved-Previously

  • The PR changes to an existing API version in a production branch but these changes were previously reviewed and approved.
  • Should only be applied by Breaking Change reviewer (maybe open this up in the future)
  • It is desirable but not mandatory to add a link the previously approved PR in a comment on this PR.
  • I think this label will only apply for PRs to the public repo that were reviewed and approved in the private repo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment