From a782ea61b16a50907b56b1026ab6d5c944a03e33 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 9 Oct 2026 05:09:16 +0000 Subject: [PATCH 1/6] Initial plan From 5b222e5a2ffdc0ddac18bf9def22baf21d7229eb Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 9 Oct 2026 05:10:27 +0000 Subject: [PATCH 2/6] docs: clarify Azure policy for RequiredStatusChange Co-authored-by: jianingwang123 <141212663+jianingwang123@users.noreply.github.com> --- docs/rules/1025.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/docs/rules/1025.md b/docs/rules/1025.md index 94e7bb34..733c4f1d 100644 --- a/docs/rules/1025.md +++ b/docs/rules/1025.md @@ -2,7 +2,18 @@ **Description**: Checks whether an existing property's `required` status is changed from the previous specification. -**Cause**: This is considered a breaking change in the same api-version but not breaking in new api-version . +**Cause**: Under this rule's semantics, this is considered a breaking change in the same api-version but not in a new +api-version. This does not by itself define Azure REST API breaking-change policy. + +**Important — Azure policy**: Requiredness changes affecting the wire contract can still require breaking-change review +in a new API version. Azure policy treats changing existing input/output fields from required to optional as +breaking-change review cases. In particular, do not assume required-to-optional changes to response/resource fields +are automatically safe just because the api-version changed. + +Azure specs policy and validation runner mapping can treat `RequiredStatusChange` as breaking in PR validation. +The example below illustrates rule semantics, not the full Azure review policy. A finding in a new API version is not +by itself evidence of a tooling/documentation mismatch; follow the Azure breaking-change review process rather than +starting with suppression unless there is grounded evidence that the finding is incorrect. **Example**: `required` status for parameter `b` is changed from `false` to `true` without revising api-version. From 0f0998f59d4e03d475b83c416f0312a0d1e6fca4 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Sat, 10 Oct 2026 02:29:49 +0000 Subject: [PATCH 3/6] docs: remove ambiguity from requiredness change cause Co-authored-by: jianingwang123 <141212663+jianingwang123@users.noreply.github.com> --- docs/rules/1025.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/rules/1025.md b/docs/rules/1025.md index 733c4f1d..7ac1ff46 100644 --- a/docs/rules/1025.md +++ b/docs/rules/1025.md @@ -2,8 +2,9 @@ **Description**: Checks whether an existing property's `required` status is changed from the previous specification. -**Cause**: Under this rule's semantics, this is considered a breaking change in the same api-version but not in a new -api-version. This does not by itself define Azure REST API breaking-change policy. +**Cause**: Changing an existing property's `required` status is a breaking change in the same API version. +In a new API version, whether the change is breaking depends on its impact on the wire contract and Azure REST API +breaking-change policy; a new API version alone does not make it non-breaking. **Important — Azure policy**: Requiredness changes affecting the wire contract can still require breaking-change review in a new API version. Azure policy treats changing existing input/output fields from required to optional as From bc34d5ac921f6b591cac4af1139a33c77ee609ed Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Sat, 10 Oct 2026 03:23:39 +0000 Subject: [PATCH 4/6] docs: remove redundant RequiredStatusChange guidance Co-authored-by: jianingwang123 <141212663+jianingwang123@users.noreply.github.com> --- docs/rules/1025.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/docs/rules/1025.md b/docs/rules/1025.md index 7ac1ff46..b7296a00 100644 --- a/docs/rules/1025.md +++ b/docs/rules/1025.md @@ -6,16 +6,6 @@ In a new API version, whether the change is breaking depends on its impact on the wire contract and Azure REST API breaking-change policy; a new API version alone does not make it non-breaking. -**Important — Azure policy**: Requiredness changes affecting the wire contract can still require breaking-change review -in a new API version. Azure policy treats changing existing input/output fields from required to optional as -breaking-change review cases. In particular, do not assume required-to-optional changes to response/resource fields -are automatically safe just because the api-version changed. - -Azure specs policy and validation runner mapping can treat `RequiredStatusChange` as breaking in PR validation. -The example below illustrates rule semantics, not the full Azure review policy. A finding in a new API version is not -by itself evidence of a tooling/documentation mismatch; follow the Azure breaking-change review process rather than -starting with suppression unless there is grounded evidence that the finding is incorrect. - **Example**: `required` status for parameter `b` is changed from `false` to `true` without revising api-version. Old specification From fd352223aaf396743313bc020136f5e26adc2556 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Sat, 10 Oct 2026 06:00:34 +0000 Subject: [PATCH 5/6] docs: apply requested RequiredStatusChange cause wording Co-authored-by: jianingwang123 <141212663+jianingwang123@users.noreply.github.com> --- docs/rules/1025.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/rules/1025.md b/docs/rules/1025.md index b7296a00..cd01ed41 100644 --- a/docs/rules/1025.md +++ b/docs/rules/1025.md @@ -2,9 +2,8 @@ **Description**: Checks whether an existing property's `required` status is changed from the previous specification. -**Cause**: Changing an existing property's `required` status is a breaking change in the same API version. -In a new API version, whether the change is breaking depends on its impact on the wire contract and Azure REST API -breaking-change policy; a new API version alone does not make it non-breaking. +**Cause**: Changing an existing property's required status is a breaking change in the same api-version. +In a new api-version, whether the change is breaking depends on its impact on the wire contract and Azure REST API breaking-change policy. **Example**: `required` status for parameter `b` is changed from `false` to `true` without revising api-version. From b436b828e4681fbf5be6b6c9ec00f0d6db8b95db Mon Sep 17 00:00:00 2001 From: "Jianing Wang (MSFT)" <141212663+jianingwang123@users.noreply.github.com> Date: Sat, 10 Oct 2026 14:07:25 +0800 Subject: [PATCH 6/6] Fix formatting in RequiredStatusChange documentation --- docs/rules/1025.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rules/1025.md b/docs/rules/1025.md index cd01ed41..b952cd46 100644 --- a/docs/rules/1025.md +++ b/docs/rules/1025.md @@ -2,7 +2,7 @@ **Description**: Checks whether an existing property's `required` status is changed from the previous specification. -**Cause**: Changing an existing property's required status is a breaking change in the same api-version. +**Cause**: Changing an existing property's `required` status is a breaking change in the same api-version. In a new api-version, whether the change is breaking depends on its impact on the wire contract and Azure REST API breaking-change policy. **Example**: `required` status for parameter `b` is changed from `false` to `true` without revising api-version.