Codecov Report

Merging #266 (64432e7) into dev (1213767) will increase coverage by 0.48%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #266      +/-   ##
==========================================
+ Coverage   64.17%   64.66%   +0.48%     
==========================================
  Files          19       19              
  Lines        5571     6100     +529     
  Branches     1410     1446      +36     
==========================================
+ Hits         3575     3944     +369     
- Misses       1230     1378     +148     
- Partials      766      778      +12     

Ok everything works except fsdocs. It looks like fsdocs needs to be updated to work without requiring net core 3.1.

What is the rationale for removing netcore 3.1 and netstandard 2.1 support in the back-ends and core library? Both will be fully supported for a couple of years yet (even beyond net5.0); are there net5.0 features/libraries expected to become dependencies?

One motivation is to not ask and users/developers to install two separate dotnet versions (3.1 and 5.0) just to run tests and recreate documentation as it is currently the case. Actually I'm confused about this and I don't know why having 5.0 sdk only was not enough to run a netcoreapp3.1 test application as we observed. The table here says net5.0 is compatible with netcoreapp3.1.

The other motivation is the information in many places (one example) saying net5.0 is now the suggested target for cross-platform libraries. I like the simplicity this brings and I'm fine with saying you need dotnet 5 to use DiffSharp, which also ensures the users will need to get the latest runtime environment and benefit from latest performance improvements, F# 5 features etc.

Another thing can be F# 5 support. Although I don't know how closely this is tied to dotnet version.

If there is an easy way for supporting both (without requiring both), I'm fine with that too. I think it should be possible to target multiple frameworks like <TargetFrameworks>netcoreapp3.1;net5.0</TargetFrameworks>. I will leave the choice here to @dsyme.

The fsdocs failure might be down to roll forward policy: https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-apps-roll-forward

Ease of dev is a reasonable reason. I would suggest dual-targeting the consumer-facing stuff, though, so long as there are no dependencies that make that a problem. (You should be able to multi-target netstandard2.1 and netcoreapp3.1 without having netcore3.1 installed).

Other notes:

The net 5.0 runtime can execute a netcore3.1 application, but only if the runtime config asks for it to do so. By default, the runtime config for an application compiled against netcore3.1 will request netcore3.1.0, and (as in cgravill's link) it will be unhappy if you only have net5.0 installed.

You don't need to target net 5.0 to use F#5 (just be compiling with the .net 5.0 sdk), but I don't know whether there are features that will require a net 5.0 target (my understanding is that it should be good for anything >= netstandard2.0, but I could be mistaken). That is, it should be possible to use F#5 in the library code-base without requiring the consumer to use net5.0 for their own work.

This is a long, long rabbit hole to go down.

1. We need to use F# 5, since it has features we need (e.g. open type, string interpolation, nullable interop).

2. Using F# 5 requries an install of .NET 5 SDK, which only installs .NET 5 Runtime by default.

3. The fsdocs tool requires a .NET Core 3.x runtime and it appears running fsdocs on .NET 5 Runtime is a total PITA. I've recorded this issue here: Error running fsdocs on .NET 5.0.100 SDK fsprojects/FSharp.Formatting#620. It seems so simple, but resolving this seems to require major work in fsdocs repository and also involves updating both FAKE and paket to be net5.0-aware versions. I've tried doing that but there are a whole series of obscure errors along the way

I'm annoyed this is not simple. For now I recommend we just stick to what we have until fsdocs is sorted out.

...I don't know whether there are features that will require a net 5.0 target ...

There is nothing that requires a net 5.0 target. Any applications in this repository should be able to specify

<RollForward>LatestMajor</RollForward>

or

<RollForward>Major</RollForward>

and things should work ok

Is it possible to adjust the fsdocs call?

If we were doing a dotnet XYZ.dll I understand it could be adjusted to dotnet --roll-forward LatestMajor XYZ.dll like this

with a runtime config:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet#runtime-options

but that doesn't seem to be supported with .NET Tools call. Perhaps we could still use the DOTNET_ROLL_FORWARD environment variable? All this assumes that fsdocs would just run on .NET 5.0

fsprojects/FSharp.Formatting#621 should allow fsdocs to roll forward

It turns out running fsdocs (and any F# tool based on FSharp.Compiler.Service which processes scripts) on .NET Core 5.0 requrires this core F# fix and an update to FCS

So this will take a little while to come through the pipe

I updated to fsdocs 8.0.0 which will hopefully allow us to use .NET 5 only

OK that worked 👍

Note moving DiffSHarp.Core and the reference backend from netstandard2.1 to net5.0 was not necessary and probably not desireable - these should be kept independent of any particular runtime.

I'll likely revert that part of this change however it is farily harmless for now

Also, I believe we could have kept all the tests on netcoreapp3.1 and just used RollForward.