go-sdk-breaking-change-review.md

Breaking change review for Go management SDK

Routine tasks

We have two routine tasks related with Go Management SDK breaking change review process:

1. For all public/private PR for management API change, we need to approve the Go SDK breaking changes if exist. The review should be completed in around two business day. Refer: https://aka.ms/azsdk/pr-getting-help for more detail about spec review process. So, the steps are:

• Every day, we need to monitor two boards: public repo PRs, private repo PRs.
• If there are PRs in the list, then we need to check each of the PR to see the reason of the Go Breaking Change label.
• If the breaking changes are from the spec change, the Swagger BreakingChange or the Breaking Change(Cross-Version) pipeline result has the corresponding spec breaking change info, and the PR has the BreakingChange-Approved-xxx label. An example here: Azure/azure-rest-api-specs#30800.
• We need to follow the breaking change suppression process to approve the breaking changes. Refer this doc: http://aka.ms/azsdk/sdk-suppression.
• Else, we need to determine if it is a false alert.
• Read the next part to see the example of different breaking changes and false alert.

2. For Go management SDK release, if the release is for stable version and contains breaking changes, we need to let architect to approve the major version bump in the release PR. So, we need to find out in which spec change PRs that the breaking changes come from and provide such info to architect. So, the steps are:

• Check if a release PR is for stable version, the version is bigger than v1 and contains breaking changes.
• If so, check if the breaking changes are come from spec change and find the corresponding spec change PRs.
• Leave a comment with The breaking changes are introduced and approved in [this PR](link). in the release PR.
• Let SDK owner to confirm the info.
• Leave a comment as @JeffreyRichter , please approve this major version release by adding label of Approved Major Version, thanks. to involve the architect to approve.
• An example is here: Azure/azure-sdk-for-go#23343.

Examples of breaking changes

1. Breaking changes caused by previous directive Sometimes we use directive to fix some SDK generation issues. When spec update, spec author may not have context about such directive, which will cause the breaking changes. We need to update the directive to mitigate the breaking changes in such case. Example: Azure/azure-rest-api-specs#31446.
2. First stable version For first stable version, the breaking changes are valid. So we only need to add the Breaking-Change-Go-Approved label. Azure/azure-rest-api-specs#31604.
3. Config changes Such PR is not related with spec change, and it always opened by SDK team. So we only need to add the Breaking-Change-Go-Approved label. Example: Azure/azure-rest-api-specs#31776.