{Core} Extension Breaking Change Announcement Instruction#30975
{Core} Extension Breaking Change Announcement Instruction#30975
Conversation
ReaNAiveD
requested review from
bebound,
calvinhzy,
evelyn-ys,
jiasli,
jsntcy,
kairu-ms,
necusjz and
zhoxing-ms
as code owners
️✔️AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
microsoft-github-policy-service
bot
added
Auto-Assign
ReaNAiveD
requested review from
AllyW,
Greedygre,
Juliehzl,
howang-ms,
wangzelin007 and
yanzhudd
as code owners
ReaNAiveD
force-pushed
the
bc_announce_update
branch
from
6c42404 to
f209cca
Compare
| * Service Owned Module | ||
| * Service Team should create a Pull Request that create the pre-announcement several sprints ahead Breaking Change Window. | ||
| * The pre-announcement should be released ahead of Breaking Change Window. | ||
| * The pre-announcement should be released at least **2** sprints ahead of Breaking Change Window. |
There was a problem hiding this comment.
usually I suppose sprint will vary across team, but monthly basis is often adopted.
If we put as 1-month policy above(Line 32), we might keep it aligned here, rather than 2 sprints, right?
| * The pre-announcement should be released ahead of Breaking Change Window. | ||
| * The pre-announcement should be released at least **2** sprints ahead of Breaking Change Window. | ||
| * **Service Owned Module** | ||
| * Service Team should create a Pull Request that adds the pre-announcement at least **2** sprints ahead of Breaking Change Window. |
| * The pre-announcement should be released at least **2** sprints ahead of Breaking Change Window. | ||
| * **Service Owned Module** | ||
| * Service Team should create a Pull Request that adds the pre-announcement at least **2** sprints ahead of Breaking Change Window. | ||
| * The pre-announcement should be released at least **2** sprints ahead of Breaking Change Window. |
|
|
||
| register_required_flag_breaking_change('bar foo', '--name') | ||
| register_default_value_breaking_change('bar foo baz', '--foobar', 'A', 'B') | ||
| register_default_value_breaking_change('bar foo baz', '--foobar', 'A', 'B', target_version='May 2025') |
There was a problem hiding this comment.
May I ask if our target version is currently using the date style? How to ensure consistency in the target version style of all extensions?(such as defining enumeration)
There was a problem hiding this comment.
I support using plain text in this PR, so that we could support date style. This will be beneficial for an upcoming breaking change in an extension, which could occur in the coming months.
I don't believe we need to ensure consistency in the target version style, as version numbers are unpredictable for both developers and customers. While they know the version, they don't know when it will be released. Therefore, it is more flexible to support both date and version formats.
There was a problem hiding this comment.
Yes, I agree with your~ But what I mean is that since we all use date styles, is it necessary to have a unified style to avoid some people writing the wrong date or inconsistent date styles? Such as some people write May 2025 while others write 2025-05、2025/05、2025 Build Sprint.....
There was a problem hiding this comment.
It is not easy to constraint. I think it's ok to keep the flexibility of a field with any str.
Usually, developers would follow the example in doc. And I will also add instructions about date format in doc.
6 participants
Related command
Description
Testing Guide
History Notes
This checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.