dotnet/fsharp von innen: Compiler-Bau, Branch-Modell und der RFC-Weg der Sprache F#

Compiler, Kernbibliothek und Sprachdienst in einem Repository

Das Repository dotnet/fsharp bündelt vier Teile: den F#-Compiler, die F#-Kernbibliothek FSharp.Core, den F#-Sprachdienst als Komponente FSharp.Compiler.Service und die Tooling-Integration für Visual Studio. Die Metadaten zeigen 4.323 Sterne, 872 Forks und 1.253 offene Issues; die Codebasis ist selbst in F# geschrieben und steht unter der MIT-Lizenz, nachgewiesen über License.txt.

Entwickelt werden kann laut README auf jedem Betriebssystem, das .NET unterstützt. Voraussetzung ist das .NET SDK, dessen exakt benötigte Version in der Datei global.json im Stammverzeichnis festgelegt ist. Mit 1.253 offenen Issues gehört das Projekt zu den größeren Compiler-Repositories im .NET-Ökosystem, was auch die vielen Contributing-Anleitungen erklärt, die das README auffährt.

build.cmd mit oder ohne Visual Studio, sonst build.sh

Auf Windows lautet der Kommandozeilen-Build build.cmd, und dieser Build hängt an einer installierten Visual-Studio-Instanz. Wer den Compiler ohne diese Abhängigkeit bauen will, ruft build.cmd -noVisualStudio auf. Nach Abschluss öffnet man entweder FSharp.slnx oder VisualFSharp.slnx; die zweite Lösung ist größer, enthält aber zusätzlich die F#-Tools für Visual Studio samt Infrastruktur.

Unter Linux und macOS genügt ./build.sh, anschließend öffnet man FSharp.slnx. Das README betont, dass praktisch nur das Build-Skript nötig ist; Details zu Konfigurationen stehen in DEVGUIDE.md. Welche Testsuiten es gibt und wie man sie einzeln anstößt, beschreibt TESTGUIDE.md. Für größere Beiträge an der Compiler-Codebasis nennt das README die Compiler-Dokumentation in docs/index.md als Pflichtlektüre, mit Lernvideos und Architekturdiagrammen; dieselben Inhalte sind öffentlich unter fsharp.github.io/fsharp-compiler-docs publiziert, inklusive durchsuchbarer Dokumentation zu FSharp.Compiler.Service.

Preview-Pakete über Azure-Feeds und die Synchronisationsregel

Für jede Build-Schiene liefert das README NuGet-Paketauschnitte mit Feed-URLs. Die Serie 7.0.40x bietet FSharp.Compiler.Service 43.7.400-preview über den Feed dotnet7, die Serie 8.0.10x die Version 43.8.100-preview über den Feed dotnet8; beide Feeds liegen unter pkgs.dev.azure.com/dnceng und lassen sich über einen Schlüssel fsharp-prerelease in die NuGet-Konfiguration einbinden.

Eine Regel steuert die offiziellen Pakete: Die NuGet-Veröffentlichungen von FCS und FSharp.Core sind absichtlich mit SDK-Releases synchronisiert, wie das README ausdrücklich vermerkt. Nightly-Pakete erscheinen dagegen bei jedem erfolgreichen Insert in die Azure-Feeds. Wer also Compiler-Neuheiten vor dem offiziellen SDK-Zyklus testen will, geht über die Preview-Feeds, wer Stabilität braucht, wartet auf die synchronisierten offiziellen Versionen.

Drei Branchlinien vom VS-2017-Wartungszweig bis main

Das Branch-Modell besteht laut README aus drei Linien. main nimmt fast alle Beiträge auf, muss mit dem neuesten öffentlichen Visual-Studio-Release bau-, installier- und nutzbar sein, darf neue F#-Funktionen enthalten und dient als Quelle des nächtlichen VSIX. Der Zweig release/dev15.9 ist ein Langzeit-Wartungszweig für Visual Studio 2017 Update 15.9.x, für den keine Wartung erwartet wird; Änderungen landen dort nur im Bedarfsfall.

Der Zweig release/dev17.x ist der aktuelle Release-Zweig für ein bestimmtes Visual-Studio-Punkt-Release: Er übernimmt Features und Fixes von main bis zu einem Verzweigungspunkt, erhält danach selektive Cherry-Picks und wird nach dem entsprechenden Visual-Studio-Release zurück in main integriert. Für Mitwirkende bedeutet das: Normalerweise PR nach main, Kompromisse betreffen nur Fälle, die in einem bevorstehenden VS-Release landen sollen.

Sprachänderungen: erst Vorschlag, dann RFC, dann Code

Die Evolution von F#-Sprache und Kernbibliothek läuft über zwei weitere Repositories ab, bevor dieses Repository die Umsetzung sieht. Schritt eins ist das Vorschlags-Repository fsharp/fslang-suggestions: Ideen suchen, abstimmen, neue einreichen und mit der Community diskutieren. Schritt zwei betrifft Ideen, die als approved in principle markiert wurden, sie sind berechtigt für ein RFC im Design-Repository fsharp/fslang-design, wo technische Spezifikation und Diskussion stattfinden; für Tooling-Themen gibt es eigene Tooling-RFCs.

Erst Schritt drei gehört zu dotnet/fsharp: Implementierung und Tests eines RFC werden hier eingereicht. Wer Sprachänderungen direkt als Pull-Request vorschlagen will, läuft damit am Prozess vorbei. Diese Trennung erklärt auch, warum das Issue-Aufkommen des Repositories sich vor allem auf Compiler- und Tooling-Themen konzentriert.

Von Ein-Zeichen-Tippfehlern bis good first issue

Das README formuliert explizit, dass kein Beitrag zu klein sei, sogar Ein-Zeichen-Tippfehler seien willkommen. Für den Einstieg verweist es auf eine kuratierte Liste von Issues mit dem Label help wanted und auf das Label good first issue; interessierte Mitwirkende bekunden ihr Interesse in den Kommentaren des jeweiligen Issues und können dort erste Anleitung erbitten. Die Komplexität der Issues schwankt laut README stark.

Die Sprachspezifikation unter fsharp.org/specs/language-spec/ wird als Voraussetzung genannt, um bestimmte Verhaltensweisen des Compilers zu verstehen; als Beispiel nennt das README die Reihenfolge und Art der Namensauflösung, die den Code im Bereich Name Resolutions unmittelbar prägt. Der Contributor Covenant gilt als Verhaltenskodex, nachlesbar in CODE_OF_CONDUCT.md.

Preview-Releases entlang der .NET-10-Schiene

Die letzten drei Releases folgen der .NET-10-Preview-Phase: v14.0.100-preview7.25380.108 als .NET 10.0 Preview 7 vom 13. August 2025, davor v13.9.300-beta.25181.1 als Preview 3 vom 14. April 2025 und v13.9.300-beta.25124.4 als Preview 2 vom 18. März 2025. Die Compiler-Version 14 begleitet die Version-10-Laufzeit, die 13er-Schiene gehört zur Version 9.

Community-Anlaufstellen ergänzen das Bild: Mitglieder der F# Software Foundation sind zum FSSF Slack eingeladen, mit den Kanälen #compiler und #editor-support; für allgemeine Fragen empfiehlt das README den Hashtag #fsharp auf Twitter. Die Primärdokumentation der Sprache liegt auf Microsoft Learn, ihre Quellen im Repository dotnet/docs unter docs/fsharp.

Redaktionelles Fazit

dotnet/fsharp ist die Umsetzungsheimat der Sprache F# und damit relevant für alle, die Compiler, FSharp.Compiler.Service oder die Visual-Studio-Integration berühren. Wer nur F# programmiert, braucht dieses Repository nicht selbst zu bauen, sondern greift zum .NET SDK; wer Beiträge leisten will, startet bei build.cmd oder build.sh, liest die Compiler-Dokumentation in docs/index.md und sucht sich über die Labels help wanted oder good first issue ein Issue. Die Designarbeit läuft separat über fslang-suggestions und fslang-design, PRs an main sind dafür zu spät.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes