Update the global.json

[tebeco]

Update the global.json so that the SDK match package that are actually used

[tebeco]

@nblumhardt
sorry about the noise here :(

[nblumhardt]

Thanks!

[andrewlock]

Sorry, been busy lately so not been keeping up with these changes! Personally, I don't think updating the global.json here was the correct thing to do.I feel like we should use the lowest version of the global.json that allows the app to build? At the very least, we shouldn't be mandating a patch version.

.NET Core 3.0 introduced greater control over that (I wrote a post about it recently) https://andrewlock.net/exploring-the-new-rollforward-and-allowprerelease-settings-in-global-json/ so I think we could quite happily just require any 3.0 to build, and use the default latestMajor rollforward policy?

[tebeco]

Do you want a rollback PR ?
I know that there is a Rollback going on, but as the dependencies are explicitly point to 3.1.2, i tried to synchronized the SDK with it
There version are for Msft.Ext.* not for the FrameworkReference, so as you say, it's fine
I just wanted to avoid confusion by aligning things up while the repo was being updated

[andrewlock]

It's up for discussion I think, but i'm not up to speed on everything that's happening at the moment 🙂

Personally I think trying to align everything in a library project is kind of futile - once the library is used in an app, the actual version that gets used is hugely dependent on all the other versions available (and the version of the .NET Core SDK/runtime installed!)

My preference is to specify the lowest possible version of dependencies (including NuGet packages) that will work, then allow the framework to "pull up" the patch version. e.g. if we specify v. 3.0.0 of the Msft.Ext.* libraries, then this lib will work with version 3.0.0, 3.1.0, 3.1.1 etc. If we specify 3.1.2 then the library can only be used with 3.1.2... (obviously that assumes SemVer is actually working properly here, and we are actually compatible with all those versions)

[tebeco]

Yep, I understand that too, as you said it's more a discussion and choice for actual maintainer

Regarding 3.0 I probably won't agree as it will reach end of life in less than a month.
The idea for 3.0 if you still want to target it for "compatibility" would be to add a TargetFramework for netcoreapp3.0 so that everyone would be happy, even though "SemVer should be ok", it let nuget properly resolve each dependency tree specifically.

That would also make it very easy to drop a TFM moniker support once it has reached its EOL
Rather than trying to have only one binary to attempt to target everything at once