Wie .NET versioniert wird

2025-06-20

Die .NET-Runtime und das .NET SDK fügen neue Features mit unterschiedlichen Frequenzen hinzu. Im Allgemeinen wird das SDK häufiger aktualisiert als die Laufzeit. In diesem Artikel werden die Laufzeit- und die SDK-Versionsnummern erläutert.

.NET veröffentlicht alle November eine neue Hauptversion. Gleichmäßig nummerierte Releases wie .NET 6 oder .NET 8 werden langfristig unterstützt (LTS). LTS-Versionen erhalten drei Jahre lang kostenlosen Support und Patches. Ungeradzahlige Versionen werden standardmäßig unterstützt. Standardzeit-Supportversionen erhalten kostenlosen Support und Patches für 18 Monate.

Versionsverwaltungsdetails

Die .NET-Runtime verfügt über einen Major.minor.patch-Ansatz für die Versionsverwaltung, die der semantischen Versionsverwaltung folgt.

Das .NET SDK folgt jedoch nicht der semantischen Versionsverwaltung. Das .NET SDK wird schneller bereitgestellt und seine Versionsnummern müssen sowohl die zugehörige Laufzeit als auch die eigenen Neben- und Patchversionen des SDK darstellen.

Die ersten beiden Positionen der .NET SDK-Versionsnummer entsprechen der .NET-Runtime-Version, mit der sie veröffentlicht wurde. Jede Version des SDK kann Anwendungen für diese Laufzeit oder eine beliebige niedrigere Version erstellen.

Die dritte Position der SDK-Versionsnummer kommuniziert sowohl die Neben- als auch die Patchnummer. Die Unterversion wird mit 100 multipliziert. Die letzten beiden Ziffern stellen die Patchnummer dar. Nebenversion 1, PatchVersion 2 würde als 102 dargestellt. Hier ist beispielsweise eine mögliche Sequenz von Laufzeit- und SDK-Versionsnummern:

Veränderung	.NET Runtime	.NET SDK (*)	Hinweise
Erste Veröffentlichung	5.0.0	5.0.100	Erste Veröffentlichung
SDK-Patch	5.0.0	5.0.101	Die Laufzeit hat sich mit diesem SDK-Patch nicht geändert. SDK-Patch stößt an die letzte Stelle im SDK-Patch.
Laufzeit- und SDK-Patch	5.0.1	5.0.102	Runtime-Patch stößt an die Nummer des Runtime-Patches. SDK-Patch stößt an die letzte Stelle im SDK-Patch.
SDK-Funktionsänderung	5.0.1	5.0.200	Runtime-Patch hat sich nicht geändert. Neues SDK-Feature stößt an die erste Stelle im SDK-Patch.
Runtime-Patch	5.0.2	5.0.200	Runtime-Patch stößt an die Nummer des Runtime-Patches. DAS SDK ändert sich nicht.

In der vorstehenden Tabelle werden mehrere Richtlinien angezeigt:

Die Runtime und das SDK teilen Haupt- und Nebenversionen. Die ersten beiden Nummern für ein bestimmtes SDK und die Laufzeit sollten übereinstimmen. Alle vorherigen Beispiele sind Teil des .NET 5.0-Releasestreams.
Die Patch-Version der Runtime revidiert sich nur, wenn die Runtime aktualisiert wird. Die SDK-Patchnummer wird für einen Laufzeitpatch nicht aktualisiert.
Die Patchversion des SDK wird nur aktualisiert, wenn das SDK aktualisiert wird. Es ist möglich, dass für einen Laufzeitpatch kein SDK-Patch erforderlich ist.

HINWEISE:

Wenn das SDK zehn Featureupdates vor einem Laufzeitfeatureupdate erhält, wechseln die Versionsnummern in die 1000er-Serie. Version 5.0.1000 würde Version 5.0.900 folgen. Diese Situation wird nicht erwartet.
99 Patchversionen ohne eine Featureversion wird es nicht geben. Nähert sich ein Release dieser Version, wird ein Featurerelease erzwungen.

Weitere Details finden Sie im ursprünglichen Vorschlag im Dotnet/Designs-Repository .

Semantische Versionsverwaltung

Die .NET Runtime entspricht grob der semantischen Versionsverwaltung (SemVer), wobei die Verwendung der MAJOR.MINOR.PATCH Versionsverwaltung verwendet wird, wobei die verschiedenen Teile der Versionsnummer verwendet werden, um den Grad und die Art der Änderung zu beschreiben.

MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]

Die optionalen Teile PRERELEASE und BUILDNUMBER sind nie Bestandteil von unterstützten Versionen und sind nur in nächtlichen Builds vorhanden, die lokal aus Quellzielen und nicht unterstützten Vorschauversionen erstellt werden.

Runtime-Versionsnummernänderungen

MAJOR wird einmal pro Jahr erhöht und kann Folgendes enthalten:
- Erhebliche Änderungen am Produkt oder eine neue Produktrichtung.
- Die API hat bahnbrechende Änderungen eingeführt. Die Messlatte zum Akzeptieren von aktuellen Änderungen hoch liegt.
- Eine neuere MAJOR Version einer vorhandenen Abhängigkeit wird übernommen.
Hauptversionen werden einmal pro Jahr eingeführt, bei gleichmäßig nummerierten Versionen handelt es sich um langfristig unterstützte Releases (LTS, Long-Term Supported). Die erste LTS-Version mit diesem Versionsverwaltungsschema ist .NET 6. Die neueste Nicht-LTS-Version ist .NET 9.
MINOR wird erhöht, wenn:
- Der Oberflächenbereich der öffentlichen API wird hinzugefügt.
- Es wird ein neues Verhalten hinzugefügt.
- Eine neuere MINOR Version einer vorhandenen Abhängigkeit wird übernommen.
- Es wird eine neue Abhängigkeit eingeführt.
PATCH wird erhöht, wenn:
- Fehlerkorrekturen werden vorgenommen.
- Unterstützung für eine neuere Plattform wird hinzugefügt.
- Eine neuere PATCH Version einer vorhandenen Abhängigkeit wird übernommen.
- Jede andere Änderung passt nicht zu einem der vorherigen Fälle.

Wenn mehrere Änderungen vorhanden sind, wird das höchste Element, das von einzelnen Änderungen betroffen ist, erhöht, und die folgenden werden auf Null zurückgesetzt. Wenn beispielsweise MAJOR inkrementiert wird, MINOR.PATCH werden sie auf Null zurückgesetzt. Wenn MINOR erhöht wird, wird PATCH auf Null zurückgesetzt, während MAJOR gleich bleibt.

Versionsnummern in Dateinamen

Die für .NET heruntergeladenen Dateien tragen die Version, zum Beispiel dotnet-sdk-5.0.301-win-x64.exe.

Vorschauversionen

Der Versionsnummer von Vorschauversionen ist ein -preview.[number].[build] angehängt. Beispiel: 6.0.0-preview.5.21302.13.

Wartungsversionen

Nachdem eine Veröffentlichung beendet wurde, beenden die Release-Branches in der Regel die Erstellung täglicher Builds und beginnen stattdessen mit der Erstellung von Wartungsbuilds. Der Versionsangabe von Wartungsversionen ist ein -servicing-[number] angehängt. Beispiel: 5.0.1-servicing-006924.

.NET-Runtime-Kompatibilität

Die .NET-Runtime behält ein hohes Maß an Kompatibilität zwischen Versionen bei. .NET-Apps sollten nach dem Upgrade auf eine neue größere .NET-Runtime-Version weiterhin funktionieren.

Jede Hauptversion von .NET Runtime enthält absichtliche, sorgfältig überprüfte und dokumentierte breaking changes. Die dokumentierten änderungen sind nicht die einzige Quelle von Problemen, die sich nach dem Upgrade auf eine App auswirken können. Beispielsweise kann eine Performanceverbesserung in der .NET-Runtime (die nicht als Änderung, die Kompatibilitätsprobleme verursacht, betrachtet wird) latente App-Threadingfehler aufdecken, die dazu führen, dass die App nicht auf dieser Version funktioniert. Es wird erwartet, dass große Apps nach dem Upgrade auf eine neue .NET-Runtime-Hauptversion einige Korrekturen erfordern.

Standardmäßig sind .NET-Apps so konfiguriert, dass sie auf einer bestimmten .NET-Runtime-Hauptversion ausgeführt werden. Daher wird dringend empfohlen, die App auf eine neue .NET-Runtime-Hauptversion zu aktualisieren. Testen Sie die App dann nach dem Upgrade erneut, um Probleme zu identifizieren.

Angenommen, ein Upgrade über die App-Neukompilierung ist nicht machbar. In diesem Fall stellt die .NET-Runtime zusätzliche Einstellungen bereit, mit denen eine App auf einer höheren größeren .NET-Runtime-Version ausgeführt werden kann als für die Version, für die sie kompiliert wurde. Diese Einstellungen ändern nicht die Risiken, die mit dem Upgrade der App auf eine höhere größere .NET-Runtime-Version verbunden sind, und es ist weiterhin erforderlich, die App nach dem Upgrade erneut zu testen.

Die .NET-Runtime unterstützt das Laden von Bibliotheken, die auf ältere .NET-Runtime-Versionen abzielen. Eine App, die auf eine neuere größere .NET-Runtime-Version aktualisiert wird, kann auf Bibliotheken und NuGet-Pakete verweisen, die auf ältere .NET-Runtime-Versionen abzielen. Es ist unnötig, die Ziellaufzeitversion aller Bibliotheken und NuGet-Pakete, auf die von der App verwiesen wird, gleichzeitig zu aktualisieren.

Freigeben über