Erneute Umbenennung: 18 Monate sind nun der "Standard Support" für .NET

Inhaltsverzeichnis

Seit der Einführung von .NET Core als plattformneutrale und modulare Alternative zum klassischen, Windows-basierten .NET Framework im Jahr 2016 bietet Microsoft zwei verschiedene Laufzeiten für den Support an: Ursprünglich gab es einen "Current Release"-Support von 12 Monaten für einige Versionen und einen "Long-term-Support" (LTS) über 36 Monate. Die Laufzeit für "Current Release"-Unterstützung wurde dann im November 2021 auf 18 Monate erhöht – und gilt auch nachträglich für .NET 5.0.

Der Dotnet-Doktor – Holger Schwichtenberg

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

Dieser Stand findet sich aktuell auch noch auf der offiziellen Support-Seite auf dem Microsoft-Webserver: "Customers can choose Long Term Support (LTS) releases or Current releases. The quality of all releases is the same. The only difference is the length of support. LTS releases get free support and patches for 3 years. Current releases get free support and patches for 18 months."

Daraus ergibt sich die folgende Support-Tabelle, nach der nur noch .NET Core 3.1 und .NET 6.0 Fehler- und Sicherheitsproblembehebungen bekommen:

Über Short-term-Support zum Standard-Support

Am 4. Juni 2022 kündigte Microsoft dann auf GitHub die Umbenennung des "Current Release" in "Short Term Support" (STS) an. Das wurde am 9. August dann auch im .NET Blog allgemein verkündet: "We recently changed the 'Current' name to 'Short Term Support (STS)'."

Seit 14. Oktober 2022 heißt die Supportdauer jetzt aber "Standard Support". Im Blogeintrag zu .NET 7.0 Release Candidate 2.0 wird "Standard Support" verwendet, ohne die erneute Umbenennung nochmals zu thematisieren.

Deterministische Release-Zyklen

Seit .NET 5.0 erscheinen neue .NET-Versionen immer im November eines Jahres. Dabei sind ungerade Nummern im kurzen, nun "Standard" genannten Support und die geraden Nummern haben die längere Unterstützung (siehe Abbildung):

Unbegrenzter Support für .NET Framework 4.8

Eine Unterstützungsdauer von vielen Jahren wie beim klassischen .NET Framework gibt es im modernen .NET leider nicht mehr. Für das klassische .NET Framework gilt weiterhin die Bindung an den Betriebssystem-Support: "Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed."

Zudem hat Microsoft immer wieder verkündet, dass die Unterstützung für .NET Framework 4.8 unbegrenzt sein wird, zum Beispiel:

• ".NET Framework 4.8 … will continue to ship with Windows (much of Windows depends on .NET Framework)"
• ".NET Framework will always be a part of Windows"

Im August 2022 ist das kleine Update .NET Framework 4.8.1 erschienen. Laut Microsoft-Blogeintrag wird eine Aktualisierung der Windows-Rechner auf Version 4.8.1 nicht erzwungen – auch Version 4.8 solle demzufolge weiterhin Aktualisierungen zur Fehlerbehebung erhalten.

Gravierendere Breaking Changes nur im modernen .NET

Für die Zukunft ist aber nicht ausgeschlossen, dass Microsoft Nutzerinnen und Nutzer zur Aktualisierung auf 4.8.x zwingt. Solche vorzeitigen Zwangsupdates hat es in der Vergangenheit immer wieder gegeben: beispielsweise endete der Support für .NET Framework 4.5.2, 4.6 und 4.6.1 vorzeitig am 26. April 2022.

Aufgrund der hohen Kompatibilität sind solche Aktualisierungen im klassischen .NET Framework aber kein Problem. Beim modernen .NET gibt es hingegen umfangreiche Breaking Changes mit jeder zweiten Version. Auch beim klassischen .NET Framework gab es immer wieder kleinere Breaking Changes, die waren aber seltener und deutlich weniger gravierend.

(map)