Allow specifying exact module versions in requirements.psd1 as opposed to x.* convention

[AnatoliB]

[TylerLeonhardt]

This should probably also include x.x.* since Azure PowerShell is allowed to introduce breaking changes at the x.* level.

[AnatoliB]

@TylerLeonhardt This specific issue is about allowing precise module versions, without * on any level. We may want to make the specification rules more flexible than they are now, but there is no issue currently filed on this, and we are not considering this for GA at this point.

By the way, Az module owners claim that they officially allow breaking changes only on new major versions (e.g. allowed between 2.1 and 3.0, but not between 2.1 and 2.2). Do you have a reason to believe this is not true? Of course, it's hard to guarantee unintentional breaking changes, and this is exactly why we want to give the user a way to opt-out from automatic upgrades by specifying precise versions.

[TylerLeonhardt]

Az module owners claim that they officially allow breaking changes only on new major versions

How do individual module (Az.Aks for example) versions impact the version of Az the meta model version? I think I've heard from @joeyaiello that what you're saying use to not be true in the 1.x days of Azure PowerShell... But if you say that is not the case today, I believe you.

Still, once managed deps is opened to all modules on the Gallery, we can't guarantee that any module is following that pattern, so the ability to pin to a specific version (this issue), or specify wildcards at the patch level will allow this feature to be flexible.

The 3rd point is to allow prerelease versions - something that I don't think is possible at all today because -AllowPrerelease is not specified to Save-Module

[AnatoliB]

I don't know if the individual Az.* modules are strictly following these rules. The overall Az releases should. Taking a dependency on the entire Az is the primary use case we want to address right now, while also allowing precise versions for both Az and Az.*, and this is what we are currently planning for GA. I can definitely see the value of providing more flexible version specifications, including prerelease versions, but we probably can GA without that and improve later. I will discuss these with the team. If these capabilities look urgent/important to you, please feel free to file separate issues.