Minimum required sdk version is making dev wf painful

[ViktorHofer]

• This issue is blocking
• This issue is causing unreasonable pain

dotnet/runtime@e0e752a updated the minimum required SDK specified in the repo's global.json file: dotnet/runtime@e0e752a#diff-274660eb4b1b1d963a330b471e10f41cR3.

I don't see any reason why Arcade bumps both the locally aquired sdk's version and the minimum required sdk version. We have a policy in place in dotnet/runtime that forbids us to merge and infrastructure breaking changes outside of our monthly rollouts. These auto-updates break our promise.

cc @mmitche @safern @markwilkie

[markwilkie]

My understanding of the current policy is that all SDK updates go through tactics which concerns can be addressed as required. (I believe this happened in this case as well)

With the goal (principle) that the stack uses a consistent SDK - do you have a recommend @ViktorHofer for what we should do instead?

[ViktorHofer]

With the goal (principle) that the stack uses a consistent SDK

The stack's SDK is the repo local SDK:

arcade/global.json

Line 3 in dcc5ca2

"dotnet": "5.0.100-preview.6.20310.4"

.

do you have a recommend @ViktorHofer for what we should do instead?

Yes, dependency flow should only update the repo local SDK's version but not the minimum required one. Arcade doesn't even define a minimum version in their global.json and dependency flow doesn't add it so I assume that it only updates the value if it exists.

[riarenas]

Maestro does keep them both in sync using Arcade's local version as the source of truth. the scope of the policy at the time was to include the minimum required as well, both for consistency with the repo local, and I believe one additional reason was to get more usage for dogfooding.

If the policy should change, it's a simple code change to stop keeping them both in sync.

[safern]

I think updating the minimum required SDK is painful for contributors and I'm towards not updating it that "often", however, in this case if we haven't had updated it we would not have caught a very concerning MSBuild issue that would've probably slipped through Preview6 final product, so that makes me hesitant and I like that we actually dogfood the SDK as customers would do.

[dougbu]

We prefer the current state for the dotnet/aspnetcore repo. In that repo, we purposefully do not allow the SDK to roll forward and have disabled use of a globally-installed SDK. Please at least give repos the option to maintain the current behaviour.

[ViktorHofer]

Don't get me wrong here, we definitely want to dogfood the latest SDK and we already do that via the repo local one. The issue that Santi mentioned should have been caught by dotnet/installer or Microsoft/msbuild and I suspect a test hole there.

dotnet/runtime allows using a globally installed SDK if it meets the minimum required version. @dougbu why would you want to prevent that?

[dougbu]

why would you want to prevent that?

For consistency our preference remains sticking w/ the repo-local SDK. We're not going to change that.

[ViktorHofer]

I think updating the minimum required SDK is painful for contributors and I'm towards not updating it that "often", however, in this case if we haven't had updated it we would not have caught a very concerning MSBuild issue

In the past dotnet/runtime updated the SDK more often than Arcade (which sticked on 3.1.101 for several months and just recently started dogfooding 5.0 with the TFM change). We will most likely update the minimum required SDK every month with the monthly infrastructure rollout (ie dotnet/runtime#37706). The pain at the moment is that Arcade updates it outside of our rollout window.

We want to be able to opt-out of the existing behavior and have full control over the minimum required SDK version. Example of the opt-out switch:

  "tools": {
    "dotnet": "5.0.100-preview.6.20310.4",
    "updateSdkAttribute": "true"
  },

[mmitche]

I think updating the minimum required SDK is painful for contributors and I'm towards not updating it that "often", however, in this case if we haven't had updated it we would not have caught a very concerning MSBuild issue

In the past dotnet/runtime updated the SDK more often than Arcade (which sticked on 3.1.101 for several months and just recently started dogfooding 5.0 with the TFM change). We will most likely update the minimum required SDK every month with the monthly infrastructure rollout (ie dotnet/runtime#37706). The pain at the moment is that Arcade updates it outside of our rollout window.

We want to be able to opt-out of the existing behavior and have full control over the minimum required SDK version. Example of the opt-out switch:

  "tools": {
    "dotnet": "5.0.100-preview.6.20310.4",
    "updateSdkAttribute": "true"
  },

Doesn't the fact that the tools.dotnet attribute gets updated across the board (the SDK used to build the product) effectively mean that an arcade rollout that updates the dotnet version will bring in a potentially breaking change (e.g. nuget update)?

Is this primarily about dev workflow?

[ViktorHofer]

Doesn't the fact that the tools.dotnet attribute gets updated across the board (the SDK used to build the product) effectively mean that an arcade rollout that updates the dotnet version will bring in a potentially breaking change (e.g. nuget update)?

Not necessarily. As an example, you updated the Arcade SDK a month ago to benefit from improvements made in NuGet: 1a7aa80. For that change alone we would never update the minimum required SDK as there's close to zero impact for developers working on libraries.

Is this primarily about dev workflow?

Yes, the minimum required SDK version determines if a globally installed SDK can be used in the repository. Our community and our devs don't want us bumping the minimum required version up for an artificial reason as it requires them to install a new nightly version.

There are definitely cases where updating the minimum required SDK can't be avoided, e.g. for NuGet or VSTest features that we take a dependency on (ie dotnet test support or NuGet Static Graph restore).

We have helper files like our dotnet.cmd and .sh scripts or the build -vs command that open VS with the repo local SDK but that's insufficient. People still want to use their globally installed SDK (me included) and would appreciate it if the minimum required SDK version isn't bumped randomly.

EDIT: If Arcade takes a dependency on a new SDK feature then the min version should be updated, hence it makes sense for Arcade to define a minimum required version in their global.json as well.

[dougbu]

Backing up a bit, I was wrong in

For consistency our preference remains sticking w/ the repo-local SDK. We're not going to change that.

and similar comments. The perception is the aspnetcore repo is not as approachable as it could be. One step toward approachability would be to support system-wide SDK installations. We are also considering allowing roll-forward so that individual developers could try out newer SDKs, meaning CI builds aren't the main way we'd dogfood those SDKs.

So, as @Pilchie said in a recent meeting, the ideal Arcade option for 5.0 would bump the minimum version just to the latest released version of the SDK. We might not be there yet…

Put another way, opting out of SDK changes entirely seems less important than slowing the cadence down to released versions.

[Pilchie]

I thought the initial plan we had for SDK updates at the beginning of 5.0 was to update once per preview to the last released preview except when a team came to tactics with a need to do an interim update?

Also, didn't this have implications on source build?

[Pilchie]

That seems to be what's written at https://github.com/dotnet/arcade/blob/master/Documentation/Policy/ToolsetPolicy.md#net-sdk--managed-toolset

[ViktorHofer]

I don't think we differentiated between min version and target version when the doc was written.

I still believe that arcade should specify a min version rather than keeping it in sync with the target one.

[markwilkie]

I guess I'm struggling with the business value of having what amounts to a "torn state" between the dev's box and the CI build. The intent of the doc that @Pilchie referenced is deal with issues earlier rather than later in the ship cycle. Speeding up the dev workflow, only to have it get jammed in CI seems unproductive.

Also - having written this out, I have this feeling I'm missing something big and obvious. So.....could somebody help me understand how splitting min vs. target makes sense - assuming we want to "keep up" by using each release (including previews) as they come out.