Microsoft hat laut Heise den Release Candidate 2 von .NET 11 veröffentlicht – das Framework ist damit in Reichweite der allgemeinen Verfügbarkeit, während eine Reihe von Breaking Changes noch verdaut werden muss.
Die RC-Phase ist das nützliche Signal für alle, die Upgrades planen. Die Feature-Arbeit ist abgeschlossen, die API-Oberfläche praktisch eingefroren, es bleiben Fehlerbehebung und Dokumentation. Ein RC2 im Oktober passt zu Microsofts Rhythmus, der sich auf eine neue .NET-Hauptversion pro November eingespielt hat; die vorangehende .NET-10-Linie ist die aktuelle Langzeitunterstützung.
Breaking Changes sind jetzt der Punkt, an dem gehandelt werden muss. Einzeln betrachtet sind sie klein und vernünftig – die Art Aufräumarbeit, die sich über ein Jahrzehnt Plattformentwicklung ansammelt –, in der Summe verwandeln sie ein reibungsloses Upgrade in einen Nachmittag voller Build-Fehler. Die mechanische Antwort funktioniert am besten: den Kandidaten in einen Branch holen, die gesamte Lösung bauen, die Testsuite laufen lassen und Warnungen-als-Fehler-Einstellungen prüfen. Der größte Teil zeigt sich binnen Minuten.
Zweitens lohnt ein Blick auf die Kompatibilitätsschalter. Microsoft liefert üblicherweise Opt-outs für jene Änderungen, die große Codebasen am ehesten brechen; zu wissen, welche existieren, statt sofort umzuschreiben, entscheidet oft zwischen planmäßigem Release und Stillstand.
Entwickler sollten mit der offiziellen Breaking-Changes-Dokumentation arbeiten statt mit Zusammenfassungen: Die maßgebliche Liste, die betroffenen APIs und der empfohlene Migrationspfad stehen dort und werden bis zur Veröffentlichung aktualisiert.
