Make MaxSupportedLangVersion calculation dynamic#75795
Make MaxSupportedLangVersion calculation dynamic#75795jcouv merged 5 commits intodotnet:mainfrom kasperk81:patch-1
Conversation
|
see dotnet/templating#6781 (comment), every year we need to update this file when it's time to update the templates. for .net 10: dotnet/sdk#44349 @ViktorHofer @jcouv, how do you feel about this type of scalable approach? |
jaredpar
left a comment
There was a problem hiding this comment.
Pretty sure this will break the moment people start targeting net10.0
Uses historical trend to calculate language version based on the .NET version, removing hardcoded mappings. Ensures future .NET versions automatically align with expected C# version.
|
@jcouv want to make sure you've seen this. MSBuild logic looks good but you often do the lang version updates so want to make sure you see the new setup. |
| '$(_MaxSupportedLangVersion)' == ''">$([MSBuild]::Add(9, $([MSBuild]::Subtract($(_TargetFrameworkVersionWithoutV), 5)))).0</_MaxSupportedLangVersion> | ||
|
|
||
| <!-- Cap _MaxSupportedLangVersion if it exceeds _MaxAvailableLangVersion --> | ||
| <_MaxAvailableLangVersion>13.0</_MaxAvailableLangVersion> |
There was a problem hiding this comment.
@jcouv When a new language version is released, we'll just need to update _MaxAvailableLangVersion here and make adjustments in TargetTests.cs (updating the net10.0 line and adding a net11.0 line to match net10.0's language version). This setup means we won’t need to modify anything else for new framework versions released during this period each year.
There was a problem hiding this comment.
If we still need to update this file every year when we increase the max language version, then what do we actually save by making this change over the current system?
There was a problem hiding this comment.
The current system requires two updates each year: one when a new framework version is released (around October/November, managed by dotnet/sdk) and another when a new language version is added, which is handled in this repo. With this change, we're eliminating the need for the first update, as the framework version alignment will now happen automatically.
There was a problem hiding this comment.
I see. Thanks for clarifying for me. I'll let Julien be the second sign-off here though, since he does the roslyn-side of the process usually.
There was a problem hiding this comment.
one [update] when a new framework version is released (around October/November, managed by dotnet/sdk)
@kasperk81 Would you mind sharing a link to one of those previous dotnet/sdk changes? That'll help provide more context
There was a problem hiding this comment.
@jcouv it happens in the sdk each year when templates are updated. e.g. since dotnet/sdk#44349, if we use the daily build (net10.0) and do something like:
$ dotnet new record -n record1it issues warnings:
Warning: Failed to evaluate bind symbol 'evaluatedLangVersion', it will be skipped.
Warning: Failed to evaluate bind symbol 'evaluatedLangVersion', it will be skipped.
The template "Record" was created successfully.
these type of warnings will go away when 14.0 will be introduced around july 2025 but then they will reappear around october 2025 until july 2026. pr is basically decoupling this sdkVersion + 1 to compilerLatestVersion binding so things keep working smoothly throughout the year.
|
@jcouv for second sign off |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
| '$(_MaxSupportedLangVersion)' == ''">$([MSBuild]::Add(9, $([MSBuild]::Subtract($(_TargetFrameworkVersionWithoutV), 5)))).0</_MaxSupportedLangVersion> | ||
|
|
||
| <!-- Cap _MaxSupportedLangVersion if it exceeds _MaxAvailableLangVersion --> | ||
| <_MaxAvailableLangVersion>13.0</_MaxAvailableLangVersion> |
There was a problem hiding this comment.
The comment on the C# test named LanguageVersionAdded_Canary should be updated to say _MaxAvailableLangVersion instead of MaxSupportedLangVersion. Those are the instructions we follow when adding a new language version.
jcouv
left a comment
There was a problem hiding this comment.
Done with review pass (iteration 4)
Uses historical trend to calculate language version based on the .NET version, removing hardcoded mappings. Ensures future .NET versions automatically align with expected C# version.