Update Doc

ReaNAiveD · ReaNAiveD · commit 08654887e247 · 2025-03-07T12:33:30.000+08:00
diff --git a/doc/how_to_introduce_breaking_changes.md b/doc/how_to_introduce_breaking_changes.md
@@ -29,9 +29,9 @@ You could find the next Breaking Change Release plan in our [milestones](https:/
 > 
 > Please note that providing the required info for assessment does not mean it will be assured to be green-lighted for breaking changes. Team will still make the decision based on the overall impact.
 
-### Pre-announce Breaking Changes
+### Ahead-of-1-Month Pre-announcement Policy
 
-All breaking changes **must** be pre-announced two sprints ahead Release. It give users the buffer time ahead to mitigate for better command experience. There are two approaches to inform both interactive users and automatic users about the breaking changes.
+All breaking changes **must** be pre-announced **30** days(usually **2** sprints for modules in Core CLI) ahead Release. It gives users the buffer time ahead to mitigate for better command experience. There are two approaches to inform both interactive users and automatic users about the breaking changes.
 
 1. (**Mandatory**) Breaking Changes must be pre-announced through Warning Log while executing.
 2. (*Automatic*) Breaking Changes would be collected automatically and listed in [Upcoming Breaking Change](https://learn.microsoft.com/en-us/cli/azure/upcoming-breaking-changes) Document.

Original file line number	Diff line number	Diff line change
`@@ -29,9 +29,9 @@ You could find the next Breaking Change Release plan in our [milestones](https:/`
`29`	`29`	`>`
`30`	`30`	`> Please note that providing the required info for assessment does not mean it will be assured to be green-lighted for breaking changes. Team will still make the decision based on the overall impact.`
`31`	`31`
`32`		`-### Pre-announce Breaking Changes`
	`32`	`+### Ahead-of-1-Month Pre-announcement Policy`
`33`	`33`
`34`		`-All breaking changes must be pre-announced two sprints ahead Release. It give users the buffer time ahead to mitigate for better command experience. There are two approaches to inform both interactive users and automatic users about the breaking changes.`
	`34`	`+All breaking changes must be pre-announced 30 days(usually 2 sprints for modules in Core CLI) ahead Release. It gives users the buffer time ahead to mitigate for better command experience. There are two approaches to inform both interactive users and automatic users about the breaking changes.`
`35`	`35`
`36`	`36`	`1. (Mandatory) Breaking Changes must be pre-announced through Warning Log while executing.`
`37`	`37`	`2. (Automatic) Breaking Changes would be collected automatically and listed in [Upcoming Breaking Change](https://learn.microsoft.com/en-us/cli/azure/upcoming-breaking-changes) Document.`