Closed sarahelsaig closed 2 years ago
That wasn't my experience, that's why I have added it back. What do you mean by "current" exactly?
>=6.0.202, see https://github.com/dotnet/sdk/issues/23972
That explains it, I had "6.0.102" installed on my Linux desktop. But if we have a specific minimum version requirement within the same major version that really should be documented.
I'd give us (me) a pass here, since it was a workaround for a .NET SDK bug they introduced with a patch version :D.
Anyway, we shouldn't remove the fix at least until May 22, because 6.0.200's lifecycle is still active.
In principle I agree, I'd just really dread to re-add this workaround for these 9 days and have to keep in mind to remove it and retest everything.
Even after may 22, it's not like everyone will instantly and magically switch over to the latest SDK. Why are you so eager to break backwards compatibility? Does this fix have any serious drawbacks?
Yeah, but we can still say we don't support older SDKs.
This is a risky workaround because it makes us use the compiler from NuGet instead of the SDK, which is unexpected and discouraged in the package Readme too. It's a hack that we shouldn't keep until absolutely necessary, hence me also jumping on removing it the first time this was possible.
Yeah, but we can still say we don't support older SDKs.
I suppose we can say that. (I'm not happy about it tho.) Yet the main problem is that we didn't say anything, which confused the person I least want to see confused: myself. :D Instead of deleting the code, I'm going to comment it out and add some text indicating that SDK versions prior to 6.0.102 have to uncomment it.
I'm sorry :(. Sure! prior to 202, though.
OSOE-49