Dependency check tool doesn't handle post-beta breaking changes

[jhendrixMSFT]

We have the following scenario.

armmonitor depends on [email protected] which added features for fakes/tracing.
We need to release [email protected] for a new feature. fakes/tracing are not included in this release (will return in v1.8.0-beta.1)
The PR for [email protected] with the new feature, sans fakes/tracing, fails dependency check as armmonitor@latest fails to compile.

Not sure what the rule would be here to make dependency check pass. Given that this should be a rare corner-case, it might just be simpler to add a flag to bypass dependency checks.

[jhendrixMSFT]

Another permutation.

github.com/Azure/azure-sdk-for-go/sdk/messaging/azeventgrid imports
github.com/Azure/azure-sdk-for-go/sdk/azcore/messaging: module github.com/Azure/azure-sdk-for-go/sdk/azcore@latest found (v1.7.0, replaced by ../../sdk/azcore), but does not contain package github.com/Azure/azure-sdk-for-go/sdk/azcore/messaging

Here, azeventgrid depends on [email protected]. If the version fetched by azcore@latest is semantically less that what's currently imported, then it should not perform the replacement.
I believe this error is a red herring due to the target branch being behind main.

[jhendrixMSFT]

I think that the rule should be, if a module depends on a version of azcore with a minor version greater than what's to be replaced, that we skip that module.

e.g. azfoo depends on [email protected] and we're testing [email protected] then we skip dependency checking for azfoo as that's bound to fail.

[jhendrixMSFT]

The above rule has a broken corner-case. e.g. if [email protected] contains features that aren't going to be released in [email protected] then we still can't replace the beta version with the GA version (v1.8.0 > v1.8.0-beta.N).