-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/6.0] Increment source generator assembly versions with every build #58919
Conversation
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer |
cc @danmoseley |
😄 ... do we have enough testing? what could go wrong? have we tested this locally? |
Looks like you are going to need #58220 in 6.0 as well. |
not sure what kind of testing we need here. I checked the assembly versions, and they are being correctly updated. @eerhardt @sharwell
Roslyn analysers have been shipping them with this flag turned for a while now. generators are self contained so i don't expect to leak the assembly version to someplace else. The mitigation in case of a low probability event can be handled by pinning to a higher version. |
Approved (if necessary with cherry pick of change @eerhardt mentioned). Reasoning : best practice guidance from Roslyn team expected to have significant performance effect in a scenario not meeting perf goal for GA. |
@Anipik we mentioned that we'd want to double check assembly version consistency in the build. Examine the a) nuget package, b) ref-pack/aspnet-transport package, c) ref pack file list from the official build to make sure they agree. We believe they should, but since this is the first time we're using arcade's auto-assembly version we want to make sure our build is setup correctly to ensure consistency between legs. |
* Replacement tokens in logging test baseline files Instead of using a hardcoded version of the assembly version on the logging generated baseline files used by tests we use replacement tokens and at runtime we replace them. fixes #58175
Backport of #58836 to release/6.0
/cc @Anipik
Customer Impact
Not incrementing the version number can be problematic for VBCSCompiler during reference package updates, leading to dramatic reduction in compiler throughput (for Roslyn.sln, builds are about 3x slower).
Testing
Minimal
Risk
low. Roslyn analyser already uses these guidelines for assembly version updates for analyzers.