[Breaking Change] Bypass review of BreakingChange/NewApiVersionRequired for PRs to dev branches

[heaths]

Teams should be using feature branches while working on a new api-version. It's rare - practically unheard of - for any one-and-done changes to an api-version, so going directly from a topic branch into main should be a rarity. Validation seems to expect that, though.

As such, breaking changes should probably be disabled entirely when targeting a feature branch at least following the (dev|release)[-/] regex for branch names. This seems to be a variation of #5024 but I think we should still run validation across previous previews, just not requiring checks to pass.

While working in a feature branch, it's common for teams to make changes due to:

1. Change in implementation or API
2. User feedback
3. API Stewardship Board review feedback

PRs should not be blocked in these cases as they target the feature branch. We shouldn't require breaking changes until it goes to main, though it's good to check both past previews (non-required) and GAs (required).

Related work:

• [Breaking Change] Breaking change presence should not always result in a required review #6859

[konrad-jamrozik]

Requests for avoiding detecting breaking change on the same API version:

• Service Fabric Managed Clusters - api version 2023-03-01-preview azure-rest-api-specs#23718 (comment)
• [Breaking Change] Breaking Change false positive on same API version, reported by heaths on Cognitive Services Language PR #6165
• Swagger breaking change should allow no-version-change for changes to /dev directory #5264 (comment)

Related:

• [Breaking Change] [ShiftLeft] ShiftLeft breaking change process on azure-rest-api-specs-pr is confusing and noisy #5943

[konrad-jamrozik]

Per @mikekistler: probably we should still run the checks and report breaking changes if any, but not actually fail the PR. This is because if not fixed right now, they will show up again when trying to merge to public main.

[heaths]

That's also what I said in the OP. ;)

PRs should not be blocked in these cases as they target the feature branch. We shouldn't require breaking changes until it goes to main, though it's good to check both past previews (non-required) and GAs (required).

We want partners to see the issues, but not block them on merging into feature/release branches. Just main.