Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
.NET Runtime och .NET SDK lägger till nya funktioner med olika frekvenser. I allmänhet uppdateras SDK oftare än körmiljön. Den här artikeln förklarar körningstiden och SDK-versionsnumren.
.NET släpper en ny huvudversion varje november. Även numrerade versioner, till exempel .NET 6 eller .NET 8, stöds långsiktigt (LTS). LTS-versioner får kostnadsfri support och korrigeringar i tre år. Udda utgåvor är stöd för standardperiod. Vanliga supportversioner får kostnadsfri support och korrigeringar i 18 månader.
Information om versionshantering
.NET Runtime har en major.minor.patch-metod för versionshantering som följer semantisk versionshantering.
.NET SDK följer dock inte semantisk versionshantering. .NET SDK släpps snabbare, och dess versionsnummer måste kommunicera både den synkroniserade runtime-versionen och SDK:ns egna del- och korrigeringsversioner.
De två första positionerna för .NET SDK-versionsnumret matchar den .NET Runtime-version som det släpptes med. Varje version av SDK kan skapa program för den här körningen eller en lägre version.
Den tredje positionen för SDK-versionsnumret kommunicerar både del- och korrigeringsnumret. Mindre version multipliceras med 100. De sista två siffrorna representerar patchnumret. Delversion 1, patchversion 2 representeras som 102. Här är till exempel en möjlig sekvens med körnings- och SDK-versionsnummer:
Förändring | .NET-körmiljö | .NET SDK (*) | Noteringar |
---|---|---|---|
Första utgåvan | 5.0.0 | 5.0.100 | Inledande utgåva. |
SDK-korrigering | 5.0.0 | 5.0.101 | Körmiljön ändrades inte med den här SDK-uppdateringen. SDK-korrigeringen uppdaterar den sista siffran i versionsnumret för SDK. |
Körnings- och SDK-korrigering | 5.0.1 | 5.0.102 | Körningskorrigeringen uppdaterar körningskorrigeringsnumret. SDK-korrigeringen uppdaterar den sista siffran i versionsnumret för SDK. |
Funktionsändring för SDK | 5.0.1 | 5.0.200 | Körningstidsuppdateringen ändrades inte. En ny SDK-funktion uppdaterar den första siffran i SDK-korrigeringsversionen. |
Körningstidsuppdatering | 5.0.2 | 5.0.200 | Körningskorrigeringen uppdaterar körningskorrigeringsnumret. SDK ändras inte. |
I föregående tabell kan du se flera principer:
- Runtime och SDK delar större och mindre versioner. De två första talen för en viss SDK och körtid bör matcha. Alla föregående exempel är en del av .NET 5.0-versionsströmmen.
- Korrigeringsversionen av körmiljön ändras endast när körmiljön uppdateras. SDK-korrigeringsnumret uppdateras inte för en runtime-korrigering.
- Korrigeringsversionen av SDK uppdateras endast när SDK:et uppdateras. Det är möjligt att en körningskorrigering inte kräver en SDK-korrigering.
Obs!
- Om SDK:n har 10 funktionsuppdateringar innan en körningsfunktion uppdateras, rullar versionsnumren över till 1000-serien. Version 5.0.1000 skulle följa version 5.0.900. Den här situationen förväntas inte inträffa.
- 99 korrigeringsversioner utan en funktionsversion sker inte. Om en version närmar sig det här numret tvingar den fram en funktionsversion.
Du kan se mer information i det första förslaget på dotnet/ designs-lagringsplatsen.
Semantisk versionshantering
.NET Runtime följer ungefär semantisk versionshantering (SemVer), och antar användningen av MAJOR.MINOR.PATCH
versionering, där de olika delarna av versionsnumret används för att beskriva graden och typen av ändringar.
MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]
De valfria PRERELEASE
och BUILDNUMBER
delarna är aldrig del av versioner som stöds och existerar endast i nattliga byggen, lokala byggen från källmål och icke stödda förhandsutgåvor.
Ändringar i körningsversionsnummer
MAJOR
ökas en gång om året och kan innehålla:- Betydande förändringar i produkten eller en ny produktriktning.
- API:et introducerade bakåtkompatibilitetsbrytande ändringar. Det finns höga krav för att acceptera större ändringar.
- En nyare
MAJOR
version av ett befintligt beroende antas.
Större versioner sker en gång om året, jämna versionsnummer är LTS-versioner (Long Term Support). Den första LTS-versionen med det här versionsschemat är .NET 6. Den senaste icke-LTS-versionen är .NET 9.
MINOR
ökas när:- Offentlig API-yta läggs till.
- Ett nytt beteende läggs till.
- En nyare
MINOR
version av ett befintligt beroende antas. - Ett nytt beroende introduceras.
PATCH
ökas när:- Felkorrigeringar görs.
- Stöd för en nyare plattform läggs till.
- En nyare
PATCH
version av ett befintligt beroende antas. - Andra ändringar passar inte i något av de tidigare fallen.
När det finns flera ändringar ökas det högsta elementet som påverkas av enskilda ändringar och följande återställs till noll. Till exempel, när MAJOR
ökas, återställs MINOR.PATCH
till noll. När MINOR
är inkrementerad återställs PATCH
till noll medan MAJOR
förblir densamma.
Versionsnummer i filnamn
Filerna som laddas ned för .NET har, till exempel, versionen dotnet-sdk-5.0.301-win-x64.exe
.
Förhandsversioner
Förhandsversioner har ett -preview.[number].[build]
bifogat versionsnummer. Till exempel 6.0.0-preview.5.21302.13
.
Underhållsversioner
När en version har släppts slutar versionsgrenarna vanligtvis att producera dagliga versioner och börjar i stället producera serviceversioner. Servicversioner har en komponent -servicing-[number]
som läggs till i versionen. Till exempel 5.0.1-servicing-006924
.
.NET Runtime-kompatibilitet
.NET Runtime upprätthåller en hög kompatibilitetsnivå mellan versioner. .NET-appar bör i stort fortsätta att fungera efter uppgradering till en ny större .NET Runtime-version.
Varje större version av .NET Runtime innehåller avsiktliga, noggrant granskade och dokumenterade kritiska ändringar. De dokumenterade icke-bakåtkompatibla ändringarna är inte den enda källan till problem som kan påverka en app efter uppgraderingen. En prestandaförbättring i .NET Runtime (som inte anses vara en icke-bakåtkompatibel ändring) kan till exempel exponera latenta programtrådsbuggar som gör att appen inte fungerar på den versionen. Det förväntas att stora appar kräver några korrigeringar efter uppgradering till en ny .NET Runtime-huvudversion.
Som standard är .NET-appar konfigurerade för att köras på en viss .NET Runtime-huvudversion, så omkompilering rekommenderas starkt att uppgradera appen så att den körs på en ny .NET Runtime-huvudversion. Testa sedan appen igen efter uppgraderingen för att identifiera eventuella problem.
Anta att det inte är möjligt att uppgradera via appkompilering. I så fall tillhandahåller .NET Runtime ytterligare inställningar för att göra det möjligt för en app att köras på en högre .NET Runtime-version än den version som den kompilerades för. De här inställningarna ändrar inte riskerna med att uppgradera appen till en högre .NET Runtime-version, och det krävs fortfarande att appen testas igen efter uppgraderingen.
.NET Runtime stöder inläsning av bibliotek som är avsedda för äldre .NET Runtime-versioner. En app som uppgraderas till en nyare större .NET Runtime-version kan referera till bibliotek och NuGet-paket som riktar sig mot äldre .NET Runtime-versioner. Det är onödigt att uppgradera målkörningsversionen av alla bibliotek och NuGet-paket som refereras av appen samtidigt.