React to .NET 5 branding changes

[jkotas]

No description provided.

[jkotas]

This is required to unblock dotnet/runtime#33694

[adamsitnik]

I was not sure about Mono (because it's version is 5+) so I've run the following program to see what Environment.Version.Major returns:

Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
Console.WriteLine(Environment.Version.Major);

And it does print:

Mono 5.10.0 (Visual Studio built mono)
4

Which means that this check is safe ;)

Big thanks for the PR @jkotas ! People very often break us, but very few fix us as well :)

[adamsitnik]

@billwert this is something that will most probably require a new BDN version and update in performance repo

[billwert]

@DrewScoggins how do you want to handle the mechanics of a BDN update?

[DrewScoggins]

Let me think about this. I will get an answer for this later today or tomorrow.

[jkotas]

@DrewScoggins Did you have a chance to figure out the plan for updating BenchmarkDotNet in dotnet/runtime?

[DrewScoggins]

Sorry, I was pretty busy on Friday and didn't get around to this.

From a purely mechanical standpoint all we need to do is update the version that we are referencing in the performance repo and that will push out the updated version to everywhere we run performance tests, including dotnet/runtime.

The more interesting question is how do we deal with the impact of the change on the microbenchmarks. I think our approach should be two-fold. The first is that we will need to basically do integration testing for new versions of BDN. This means running against the same version of the runtime but with different versions of BDN and comparing the results. If those look good we can go ahead and make the check-in. We should also annotate the change in all of the trends that we generate so that it is clear when looking at a graph that the BDN change occurred. This way it will be clear that a major change happened and it will be marked on the build that it occurred on.

[DrewScoggins]

@adamsitnik Do you know when you will be doing the 0.12.1 release? I would like to get some numbers collected with the it and compare them against a baseline before we make the switch over.

Also @jkotas since we have not pushed the nuget package with these changes that will likely push the ETA out.

[AndreyAkinshin]

@DrewScoggins typically, I spend 2-3 full days to release a new version of BenchmarkDotNet (I manually verify all the new changes, check the typical use-cases in all the supported environments, write release notes, etc.)
Currently, I don't have a planned release date, but I can try to find some time for the release in the nearest future.
Do you have any deadlines from your side?

[DrewScoggins]

We would like to target end of next week to get this all pushed through. Would that work with your schedule @AndreyAkinshin?

[AndreyAkinshin]

@DrewScoggins ok, if I don't find any critical issues, I will release it next week.

[DrewScoggins]

@AndreyAkinshin do we think we are still on track to make a new release of BDN today?

[AndreyAkinshin]

@DrewScoggins sorry, didn't have enough time, there were too many critical issues at work.
The new plan: I'm going to work on the v0.12.1 the whole weekend and publish the package on Monday. I hope it's OK for you.
If you need the updated version of BenchmarkDotNet right now, you can try to use 0.12.0.1339 from https://ci.appveyor.com/nuget/benchmarkdotnet and switch it to the official release once it's published.

[AndreyAkinshin]

@adamsitnik I sent you a few questions about the upcoming release yesterday. Could you please check your inbox?

[DrewScoggins]

@AndreyAkinshin Monday will be great, thanks.

[AndreyAkinshin]

@DrewScoggins BenchmarkDotNet v0.12.1 is finally available.
NuGet: https://www.nuget.org/packages/BenchmarkDotNet/0.12.1
Changelog: https://benchmarkdotnet.org/changelog/v0.12.1.html
Tweet with the announcement: https://twitter.com/andrey_akinshin/status/1247169869923135489