F# 11 in FSharp.Compiler.Service ?
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Dokumentation
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- fsharp
- Bereich
- documentation, release
Rechercherichtung
Start with the versioning comment in docs/release-notes/FSharp.Compiler.Service.fsx and the linked issues #20045 and #20818; the report also points to docs/fcs/index.md and the package README. Compare the FCS versions with their pinned FSharp.Core versions and SDK bands. Done means documenting the mapping and making it discoverable from the package README; the other release and package suggestions need maintainer decisions.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
The lastest realease of F# compiler service is tied to FSharp.Core 10
Is that intentional? Why not 11?
https://www.nuget.org/packages/FSharp.Compiler.Service/43.13.404#dependencies-body-tab
Only the previous version before uses FSharp.Core 11.
https://www.nuget.org/packages/FSharp.Compiler.Service/43.13.101#dependencies-body-tab
my agent's summary:
FSharp.Compiler.Service 43.13.101 (F# 11) has a lower version than 43.13.404 (F# 10 servicing)
Summary
Since .NET 10, the minor number of FSharp.Compiler.Service is bumped independently of the F# version. That is intended, see #20045 and #20818. But the two packages released on 2026-11-10 contradict the goal stated in #20818: the F# 11 package has a lower version than the F# 10 servicing package released the same day.
| Package | Pins FSharp.Core | SDK band | Default language version |
|---|---|---|---|
| FSharp.Compiler.Service 43.13.101 | 11.0.101 | 11.0.1xx | F# 11 |
| FSharp.Compiler.Service 43.13.404 | 10.1.404 | 10.0.4xx | F# 10 (11.0 only with --langversion:11.0) |
#20818 bumped FCSMinorVersion to 14 so that .NET 11 "is versioned higher than .NET 10.0.4xx servicing (43.13.403 / 43.13.404)" and higher than release/11.0.1xx-rc2 (43.14.101). But the build of release/11.0.1xx that shipped (dotnet/dotnet@297acf930fb0f5c07fd4e51d78e521b4ad2e5d1f) still had FCSMinorVersion 13. The bump reached release/11.0.1xx in dotnet/dotnet only with dotnet/dotnet#10868 on 2026-11-10. So 11.0.1xx shipped as 43.13.101 instead of 43.14.101.
Consequences
- nuget.org shows 43.13.404 as the latest stable version. If you want the latest FCS to get F# 11, you pick 43.13.404, which defaults to F# 10 and pins FSharp.Core 10.1.404. I did exactly that in a project that embeds FCS.
- Update tools (Dependabot, Renovate, dotnet-outdated,
dotnet list package --outdated) offer 43.13.101 → 43.13.404 to projects on F# 11. FCS pins FSharp.Core exactly, so this also moves FSharp.Core from 11.0.101 down to 10.1.404. It is a downgrade of the F# version that looks like a patch update. release/11.0.1xxin dotnet/dotnet now hasFCSMinorVersion14 andFSBuildVersion102, so the next F# 11 servicing release will probably be 43.14.102. Then F# 11.0.1xx is spread over two FCS minor versions, 43.13 and 43.14.
Other irregularities
All stable FCS versions since 43.10, with the FSharp.Core version they pin:
| FCS versions | FSharp.Core | SDK band | Published |
|---|---|---|---|
| 43.10.100 – 43.10.115 | 10.0.100 – 10.0.115 | 10.0.1xx | 2025-11 – 2026-11 |
| 43.12.100 | 11.0.100 (unlisted) | ? | 2026-03-10 |
| 43.12.201 – 43.12.204 | 10.1.201 – 10.1.204 | 10.0.2xx | 2026-03 – 2026-05 |
| 43.11.300 – 43.11.303 | 10.1.300 – 10.1.303 | 10.0.3xx | 2026-05 – 2026-08 |
| 43.12.400 – 43.12.403 | 10.1.400 – 10.1.403 | 10.0.4xx | 2026-08 – 2026-10 |
| 43.13.404 | 10.1.404 | 10.0.4xx | 2026-11-10 |
| 43.13.101 | 11.0.101 | 11.0.1xx | 2026-11-10 |
- 10.0.3xx (43.11.x) has lower versions than the older 10.0.2xx band (43.12.2xx).
- 43.12.403 and 43.13.404 are consecutive servicing releases of the same 10.0.4xx band, but the minor version changed between them.
- 43.12.100 is a listed stable package that pins FSharp.Core 11.0.100, which is unlisted. Its source (dotnet/dotnet@40cd698e5cfb2d90f436889726ee01f48d99f3ab) has
FSMajorVersion11 andFSBuildVersion100. It looks like an early F# 11 build that was published as stable. It sorts above every 10.0.3xx package (43.11.x), so update tools offer it to projects on 43.11.x.
Documentation
The only description of the scheme I found is a code comment in docs/release-notes/FSharp.Compiler.Service.fsx:
The FCS package version cannot be derived from the release notes file name: its minor number is bumped independently of the F# version (43.12.100 is F# 11.0.100, 43.12.204 is F# 10.0.204).
FST-1004 says that FCS is not part of the versioning plan. I found no table that maps FCS versions to F# versions, FSharp.Core versions or SDK bands. The package description on nuget.org doesn't say which F# version a package is for. Only the pinned FSharp.Core version tells you.
Suggestions
- Document the scheme and add a table of FCS version → F# version → FSharp.Core version → SDK band, e.g. in
docs/fcs/index.md, with a link from the package README. - Put the F# version into the package description or release notes, e.g. "FSharp.Compiler.Service for F# 11.0 (.NET SDK 11.0.1xx)".
- Unlist 43.12.100, like FSharp.Core 11.0.100, which it depends on.
- Add a check to the release process, so that a package from a newer SDK band or F# version never gets a lower version than one already published from an older band.
- Until 43.14.x ships for F# 11, mention in the release notes that 43.13.101 is the F# 11 package, even though nuget.org shows 43.13.404 as newer.
- Vorherrschende Sprache
- F#
- Sterne
- 4.3k
- Forks
- 884
- Ø Merge
- 2 T. 11 Std.
- Gemergte PRs (30 T.)
- 73
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus dotnet/fsharp
-
Needs-Triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 95/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Semantic classification cache for opened documents is never populated (written to the unopened-documents cache)Evtl. vergeben @xperiandri hat das vor 69 Tagen übernommen. OffenNeeds-Triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Needs-Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
dotnet/fsharp#20265 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Bug Needs-Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Needs-Triage
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
dotnet/fsharp#20966 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
Ähnliche Issues
-
area:mcp effort:low P5 source:agent
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
README says the land/sea mask must match the XS grid; the demo mask does not, and Step 4 worksOffendocumentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
buckai-observatory/Automated-Cloud-Removal-and-Seamless-Satellite-Image-Mosaicking-Pipeline#52 ·
Maintainer antworten meist innerhalb von 1 Tag
-
documentation
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 82/100
run-llama/llama_index#24163 ·
Maintainer antworten meist innerhalb von 1 Tag
-
documentation good first issue severity: low
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
TMHSDigital/Static_Chess#48 ·