Release of Az.Accounts 2.1.0 violates Major Version Semantic Versioning rules for Az 4.*, Az 3.*

[ChrisAtRelativity]

Description

Az 5.0.0 major version release includes the new major version release of Az.Accounts 2.1.0 with breaking changes.

Az 4.8.0 and 3.8.0 will absorb the major version breaking changes of Az.Accounts 2.1.0 as those modules do not pin to the 1.x major version of Az.Accounts. Package Details indicate >= for Az.Accounts.

The consequence is that

• Installing 3.8.0 or 4.8.0 of Az is now breaking as the latest version of Az.Accounts (2.*) is now installed instead of 1.x.
• Pinning to 3.8.0 or 4.8.0 of Az will still invite breakages in existing automation

This violates SemVer versioning rules for minor versions.

Steps to reproduce

Install-Module Az -RequiredVersion 4.8.0 -Force -Verbose -Repository PSGallery

VERBOSE: Downloading 'https://www.powershellgallery.com/api/v2/package/Az.Accounts/2.1.0'.
VERBOSE: Completed downloading 'https://www.powershellgallery.com/api/v2/package/Az.Accounts/2.1.0'.
VERBOSE: Completed downloading 'Az.Accounts'.

[ChrisAtRelativity]

One possible resolution to this issue would be to release new PATCH versions of Az 3 and Az 4 with Az.Accounts pinned to 1.*, which would resolve this issue for new installs of previously released versions of these major versions.

[dingmeng-xue]

Thanks for reporting. All az modules require the latest version of Az.Accounts. It is default behavior from the beginning. We have to release new Az.Accounts with major version this time because:

1. MS authentication library is a major change on authentication even it is not introduce breaking change.
2. One critical issue due to one historical issue in all old az modules which was fixed by Fix version compare scripts in psm1 #12356

Is there any feature blocked due to Az.Accounts major change? We will evaluate the critical of Az 3.x or 4.x patch release.

[spaelling]

Thanks for reporting. All az modules require the latest version of Az.Accounts. It is default behavior from the beginning. We have to release new Az.Accounts with major version this time because:

1. MS authentication library is a major change on authentication even it is not introduce breaking change.

2. One critical issue due to one historical issue in all old az modules which was fixed by #12356

Is there any feature blocked due to Az.Accounts major change? We will evaluate the critical of Az 3.x or 4.x patch release.

Az.Accounts 2.1 does not work with Azure Functions. That is a pretty big deal. See #13376

[erich-wang]

@spaelling, could you please call the following cmdlet before calling Connect-AzAccount to workaround:

Disable-AzContextAutosave -Scope Process 

We're going to address it in next minor release.

[ChrisAtRelativity]

@dingmeng-xue also see #552 for powershell worker.

But also, please recognize that semantic versioning of the Az module is a "contract". The expectation that I and most developers would have is that minor version updates to Az do not violate that "contract" for the API and other breaking changes for the submodules contained with Az.

We have to release new Az.Accounts with major version this time

All az modules require the latest version of Az.Accounts

Recognize that these two statements don't permit you to advertise a semantic version of the Az module and Powershell Get doesn't provide a way to install Az in a way to employ semantic versioning rules to ensure software is not broken through major releases.

MS authentication library is a major change on authentication even it is not introduce breaking change.

It does actually seem to have introduced a breaking change in that -AccountId was no longer honored. Perhaps this could be classified as a defect, though, in which case the API wasn't violated.

[Breaking Change] Removed 'Get-AzProfile' and 'Select-AzProfile'

As these are admittedly breaking changes, introducing this to the installation of Az 3/4 definitely violates semantic versioning.

MAJOR version when you make incompatible API changes

[ranarn]

Also experiencing issues with this, running a powershell script in DevOps pipeline in task AzurePowerShell@4
This is used to get token for further operations.

$ctx = Get-AzContext
$cache = $ctx.TokenCache
$token = $cache.ReadItems() | ...

Gets InvalidOperation: You cannot call a method on a null-valued expression.

Looks like .TokenCache is not working at all.

Got same error on local, and it works when downgrading to 1.9.5

[dingmeng-xue]

@ranarn , we added Get-AzAccessToken to return current access token. Please use this new approach.