F# 11 in FSharp.Compiler.Service ?
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- fsharp
- Ambito
- documentation, release
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- F#
- Stelle
- 4.3k
- Fork
- 884
- Merge medio
- 2g 11h
- PR unite (30g)
- 73
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dotnet/fsharp
-
Needs-Triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 95/100
I maintainer di solito rispondono entro 2 giorni
-
Semantic classification cache for opened documents is never populated (written to the unopened-documents cache)Forse già presa @xperiandri l’ha presa 69 giorni fa. ApertaNeeds-Triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 2 giorni
-
Needs-Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
dotnet/fsharp#20265 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Bug Needs-Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
Needs-Triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
dotnet/fsharp#20966 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di dotnet/fsharp
Issue simili
-
README says the land/sea mask must match the XS grid; the demo mask does not, and Step 4 worksApertadocumentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
buckai-observatory/Automated-Cloud-Removal-and-Seamless-Satellite-Image-Mosaicking-Pipeline#52 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 82/100
run-llama/llama_index#24163 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
btclib-org/btclib#3090 ·
I maintainer di solito rispondono entro 1 giorno
-
Translate the READMEApertadocumentation good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
asasemahmed/openboard#68 ·
I maintainer di solito rispondono entro 1 giorno