Target net10.0 and net11.0 in 8.0.0; drop netstandard2.0

[AtwoodTM]

Problem

6.0.0 targets netstandard2.0 + net10.0. netstandard2.0 is the Framework / Windows-shaped floor: it keeps FSharp.Core at 4.7.2, Microsoft.CSharp as a package reference, and the library compilable against an API surface that is no longer the product. CONTRIBUTING.md currently says not to drop it in a 6.x or 7.x change.

8.0.0 drops that floor. The target date is 10 November 2026, the scheduled .NET 11 general availability, and the issue is on the 8.0.0 milestone. Going forward this library targets the current LTS (even versions) and the current STS when one exists. Right now that is .NET 10 (LTS) and .NET 11 (STS). .NET 11 is in RC (GA expected November 2026); this issue is the preview/RC targeting work so 8.0.0 ships net10.0 + net11.0.

That is a TFM break, so the version is 8.0.0. 7.0.0 is already the Dynamitey.Community 4.0.0 switch (#130). 7.0.0 keeps netstandard2.0 and net10.0. Dynamitey.Community 4.0.0 is the last community release that still targets netstandard2.0, so Framework callers can take 7.0.0 without this TFM drop.

What this issue covers

• Package and tests compile for net10.0 and net11.0 only. No netstandard2.0, no net4x.
• CI uses a .NET 11 SDK (preview/RC until GA) and still runs on Linux, Windows, and macOS.
• Dependency floors that existed only to serve Framework / netstandard2.0 move forward with the TFMs (FSharp.Core, Microsoft.CSharp as a framework reference on modern TFMs, analyzer and test packages).
• Docs, README, CHANGELOG, CONTRIBUTING, and the "netstandard2.0 stays through 7.0.0" note are updated so they describe 8.0.0's TFMs and the LTS+STS policy.
• VersionPrefix becomes 8.0.0.

Not this issue

• Publishing 8.0.0 to nuget.org (follow-on, after this builds and tests).
• Switching Dynamitey 3.0.3 to Dynamitey.Community 4.0.0. That is 7.0.0 (#130). #29 is the older ticket.
• Vendoring Dynamitey into this repo (#107).
• NativeAOT / trimming. Still DLR; still not trim-safe.

Acceptance

• FSharp.Interop.Dynamic.fsproj TargetFrameworks is net10.0;net11.0.
• Tests build and pass on net10.0 and net11.0 on Linux, Windows, and macOS.
• The nupkg has no netstandard2.0 asset.
• README / DocFX / CHANGELOG / CONTRIBUTING state 8.0.0 TFMs and the LTS+STS rule. They no longer tell contributors to keep netstandard2.0.
• VersionPrefix is 8.0.0.

[jbtule]

Why drop .netstandard 2.0? Is FSharp.Core milestoned to drop it?

[AtwoodTM]

FSharp.Core is not dropping netstandard2.0. We are not following an F# milestone.

We are also not going to carry every old runtime. Same idea as Python: you do not keep 3.8 on life support; you ship what is supported. For this library that is current LTS plus current STS.

5.0.1.268 is still on nuget.org, as published in 2019. 6.0.0 keeps netstandard2.0 and is the maintained line for Framework and older .NET. The security and code-quality work landed there. That is the first nuget.org release since 2019. The repo sat still for a long stretch. It needed the cleanup.

7.0.0 is net10.0 and net11.0 only. Smaller footprint, supported runtimes. If you want the 7.0.0 work, move the app onto current LTS or STS. If you do not, 5.0.1.268 and 6.0.0 stay put.

Open source only stays safe with a small, current surface. That is a security-engineering choice. The threat model is not 2019's. Others may see it differently.

@dsyme @sergey-tihon would welcome your thoughts.

[jbtule]

It's a library is supposed to be consumable to provide interop. Seems weird to drop .net standard, it's just linking, there's almost no code in this framework most of the work is being done is a Microsoft library that also hasn't been updated since 2019 targeting and only targeting .net standard.

[AtwoodTM]

6.0.0 is the Standard/Framework line. 7.0.0 is LTS plus STS. Decision stands.