Bump versions using new (coherent) darc tool

[dougbu]

No description provided.

[dougbu]

CI checks are apparently failing because the latest Microsoft.EntityFrameworkCore.* dependencies aren't available where this repo is looking. Are we missing a '.NET Core 3 Dev' feed in https://github.com/aspnet/AspNetCore/blob/master/build/sources.props#L13-L24 ?

[natemcmaster]

This presents a new challenge I didn't think much about till now.

If AspNetCore-Tooling depends on Extensions build N and EntityFrameworkCore depends on build N+1, which one should darc choose? N or N+1? What if there is no build of AspNetCore-Tooling and EFCore that both depend on the same version of Extensions?

cc @mmitche

[dougbu]

@natemcmaster if we need those two to depend on a coherent set of aspnet/Extensions packages, perhaps we need to be able to specify <CoherentParentDependency>Microsoft.NETCore.App;Microsoft.Extensions.Configuration</CoherentParentDependency> or some such?

/cc @mmitche @jcagme

[benaadams]

The bot automerges EF dependencies without interaction; i.e. no review required (e.g. dotnet/efcore#14799); Extensions always requires an approval to merge, so its probably why EF is always getting ahead of Extensions with dependencies?

[benaadams]

e.g. either allow the bot to automerge Extensions (so they are both always on latest fairly close to each other); or require approval for EF so the merges can be manually coordinated?

[dougbu]

@benaadams I'm playing with a new version of the tool we hope the bot will use eventually. If the tool can't avoid inchorent dependencies, the bot will be worse.

[mmitche]

This presents a new challenge I didn't think much about till now.

If AspNetCore-Tooling depends on Extensions build N and EntityFrameworkCore depends on build N+1, which one should darc choose? N or N+1? What if there is no build of AspNetCore-Tooling and EFCore that both depend on the same version of Extensions?

cc @mmitche

The rule right now is that we choose a build that has the minimal graph depth. So if you say that some corefx dependency should be coherent with M.N.A, then it will find the corefx build producing the dependency with minimal depth to the current M.N.A version. Since, for instance, core-setup depeneds on coreclr which depends on corefx, that path to a corefx build will NOT get chosen because it is longer than M.N.A. to corefx. If no coherent build is possible (e.g. your dependency is on a new corefx binary who's build has not yet been pulled into core-setup) then the tool will error, as no coherent build is possible. In this case, you can either remove the attribute, or set the dependency to pinned.

Let's whiteboard this in the morning so I can get a better picture of what needs to happen.

[dougbu]

@natemcmaster @mmitche @jcagme

Are we missing a '.NET Core 3 Dev' feed in https://github.com/aspnet/AspNetCore/blob/master/build/sources.props#L13-L24 ?

[benaadams]

Conflicting files

eng/Version.Details.xml
eng/Versions.props

[dougbu]

FYI, despite our questions, the CI checks were successful.

[benaadams]

Looking good!

Windows.10.Amd64.ClientRS4.VS2 existing issue #7867 to be resolved by #7763

OSX.1012.Amd64.Open killed due to hitting test run timeout

Otherwise everything passes

[benaadams]

OSX.1012.Amd64.Open is timing out in corefx also; so I think that's unrelated

[mmitche]

As currently implemented, these should be attributes on Dependency, not child elements.

[dougbu]

@mmitche 🆗 Guess I thought this file was more like a MSBuild .props file.

[dougbu]

Closing this. I'm going to redo this using the correct syntax and whatever @mmitche comes up with for our second diamond dependencies (w/ Extensions).