Related command
For example:
az postgres flexible-server firewall-rule create \
--rule-name "Allow_${MY_NAME//[^a-zA-Z0-9]/_}_$DATE" \
--start-ip-address "$MY_IP" \
--resource-group "$MY_RG" \
--name "$MY_SERVER"Is your feature request related to a problem? Please describe.
Running a postgres flexible-server subcommand with a --name argument produces a warning such as:
WARNING: The --name/-n argument will be repurposed to specify the firewall rule name. The --server-name/-s argument will be introduced to specify the server name in next breaking change release(2.86.0) scheduled for May 2026.
WARNING: The --rule-name/-r argument has been deprecated and will be removed in next breaking change release(2.86.0) scheduled for May 2026.
I've written some automation for my team that drives the Azure CLI and other commands.
There doesn't appear to be any action I can take to future proof my script and explicitly opt in to the new argument handling. This confuses users of my script who see the warning and think something is wrong.
Describe the solution you'd like
It would be useful to have a global flag that allows me to opt in to a particular future breaking change version. This would allow for a graceful transition of automation using the Azure CLI and allow scripts to be forward compatible with the new breaking version at its time of release.
Describe alternatives you've considered
Currently, I have to:
- Accept the warnings and explain what they mean to users of my script
- Ensure the Azure CLI version is pinned to the current version for all of my users, including people installing it for the first time after the 2.86.0 release
- Synchronize upgrading my script and the required Azure CLI version for all of its users
Additional context
The particular changes I'm affected by were introduced in #32560, but this applies generally to all breaking changes.
Related command
For example:
Is your feature request related to a problem? Please describe.
Running a
postgres flexible-serversubcommand with a--nameargument produces a warning such as:I've written some automation for my team that drives the Azure CLI and other commands.
There doesn't appear to be any action I can take to future proof my script and explicitly opt in to the new argument handling. This confuses users of my script who see the warning and think something is wrong.
Describe the solution you'd like
It would be useful to have a global flag that allows me to opt in to a particular future breaking change version. This would allow for a graceful transition of automation using the Azure CLI and allow scripts to be forward compatible with the new breaking version at its time of release.
Describe alternatives you've considered
Currently, I have to:
Additional context
The particular changes I'm affected by were introduced in #32560, but this applies generally to all breaking changes.