Repository navigation
Unpin C# compiler version for repo #65317
Description
We're currently manually pinning the C# compiler version:
Lines 55 to 56 in ce13258
as the version currently specified from dotnet/arcade is too old:
4.1.0-2.21609.7 (81831342)
We need to ensure the compiler bits are flowing appropriately and unpin.
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
hoyosjs commentedon Aug 10, 2022
@stephentoub @AaronRobinsonMSFT I see runtime has this pinned at:
runtime/eng/Versions.props
Line 52 in 85aa052
While arcade is at
4.3.0-3.22401.3. My guess is this is not recent enough for all the ref work, file scoped classes, and other goodness the runtime has taken a dependency on? If not, then should this issue be moved to .NET 8, or should we close it and accept that we move faster than arcade with respect to language feature usage so inhouse management is better?jkoritzinsky commentedon Aug 10, 2022
When we get the P7 SDK (which I'm upgrading Arcade to as we speak), we can unpin the compiler as it has the final version of 4.4.0-1.xxxxx.
hoyosjs commentedon Aug 11, 2022
@jkoritzinsky since you are picking up the SDK upgrade after the arcade update, I'll assign this to you (and I'll link it in the PR).
jkoritzinsky commentedon Aug 11, 2022
Based on #72145 (comment), we won't be able to unpin the C# compiler upgrade just yet. There's a bug in the P7 Roslyn that wasn't fixed until after P7 was built.
4 remaining items
stephentoub commentedon Sep 13, 2022
That's fine from my perspective. I just want to make sure we get onto the official train in both servicing and main as soon as we can so that we stay up-to-date with fixes/improvements that come into the compiler.
I think we should also consider flowing compiler updates into dotnet/runtime separate from the rest of the SDK. Updating the compiler once every three months hasn't been a successful strategy.
jkoritzinsky commentedon Sep 13, 2022
I fully agree with moving to flowing compiler updates to dotnet/runtime instead of using the LKG version from the SDK. I think that will provide us with a much better experience and it will keep us up to date. It will also help us avoid some of the source-build issues we’ve had this release.
I’ll mark this as blocking servicing instead of blocking release.
stephentoub commentedon Jan 24, 2023
@jkoritzinsky, this can be closed now, right?
jkoritzinsky commentedon Jan 24, 2023
We still need to fix this in 7.0.x. I'll add that to my to-do list for tomorrow.
[release/7.0] Unpin the C# compiler version (#81247)
jkoritzinsky commentedon Apr 21, 2023
Fixed by #81247