Bump azure-cli from 2.67.0 to 2.68.0 in /pip/azure

[dependabot]

Bumps azure-cli from 2.67.0 to 2.68.0.

Changelog

Sourced from azure-cli's changelog.

How to introduce Breaking Changes in service command

Azure CLI has bi-annual breaking change releases coinciding with Microsoft Build and Ignite. Limiting breaking changes to twice a year provides a stable experience for customers while being able to keep up to date with the latest versions of Azure CLI and plan accordingly for announced breaking changes.

Breaking Changes in Azure CLI

A breaking change refers to a modification that disrupts backward compatibility with previous versions. The breaking changes could cause a customer's script or automation written in a previous version to fail.

The common examples of breaking changes include:

• Modifying the names of parameters/commands.
• Modifying the input logic of parameters.
• Modifying the format or properties of result output.
• Modifying the current behavior model.
• Adding additional verification that changes CLI behavior.

To mitigate the impact of breaking changes, Azure CLI delays breaking changes and coordinates half-yearly Breaking Change Releases that bundle multiple breaking changes together. This approach helps users plan ahead and adapt to the modifications effectively.

Breaking Change Window

The breaking change window is a designated sprint that permits the merging of service command breaking changes. Any Pull Request merged during this sprint will be included in the subsequent Breaking Change Release.

The timing of the breaking change window in Azure CLI aligns with Microsoft Build and Microsoft Ignite. It normally occurs in May for Build and November for Ignite. So please prepare beforehand to align command breaking changes with Azure CLI team accordingly.

You could find the next Breaking Change Release plan in our milestones.

It's highlighted that the introduction of breaking changes is typically prohibited within non-breaking-change window, based on what we stated above for consistency and stable tooling experience.

Exceptions to this policy may be considered under extraordinary circumstances. We understand and would like to help out. There would be high-graded justifications required to provide the info Azure CLI can access.

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

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.

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 Document.

Workflow

Overview

• CLI Owned Module
  • Service Team should create an Issue that requests CLI Team to create the pre-announcement several sprints ahead Breaking Change Window. The issue should include the label Breaking Change. The CLI team will look at the issue and evaluate if it will be accepted in the next breaking change release.
    • Please ensure sufficient time for CLI Team to finish the pre-announcement.
  • The pre-announcement should be released ahead of Breaking Change Window.
• 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.
• After releasing the pre-announcement, a pipeline would be triggered, and the Upcoming Breaking Change Documentation would be updated.

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)