Delen via

Versiebeheer van .NET

De .NET Runtime en de .NET SDK voegen nieuwe functies toe met verschillende frequenties. Over het algemeen wordt de SDK vaker bijgewerkt dan de runtime. In dit artikel worden de runtime- en SDK-versienummers uitgelegd.

.NET brengt elke november een nieuwe primaire versie uit. Even genummerde releases, zoals .NET 6 of .NET 8, zijn LTS-releases (long-term support). LTS-releases krijgen drie jaar gratis ondersteuning en patches. Oneven genummerde releases zijn standaardondersteuningsreleases (STS). Standaardondersteuningsreleases krijgen gedurende twee jaar gratis ondersteuning en patches (te beginnen met .NET 9).

Details van versiebeheer

De .NET Runtime heeft een major.minor.patch-benadering voor versiebeheer die volgt op semantische versiebeheer.

De .NET SDK volgt echter geen semantische versiebeheer. De .NET SDK publiceert sneller en de versienummers moeten zowel de uitgelijnde runtime als de eigen secundaire en patchversies van de SDK communiceren.

De eerste twee posities van het .NET SDK-versienummer komen overeen met de .NET Runtime-versie waarmee deze is uitgebracht. Elke versie van de SDK kan toepassingen maken voor deze runtime of een lagere versie.

De derde positie van het SDK-versienummer communiceert zowel het secundaire als het patchnummer. De secundaire versie wordt vermenigvuldigd met 100. De laatste twee cijfers vertegenwoordigen het patchnummer. Kleine versie 1, patchversie 2 wordt weergegeven als 102. Hier volgt bijvoorbeeld een mogelijke reeks runtime- en SDK-versienummers:

Veranderen .NET Runtime .NET SDK (*) Opmerkingen
Eerste versie 5.0.0 5.0.100 Eerste versie.
SDK-patch 5.0.0 5.0.101 Runtime is niet gewijzigd met deze SDK-patch. SDK-patch verhoogt het laatste cijfer van de SDK-versie.
Runtime- en SDK-patch 5.0.1 5.0.102 De runtime-patch verhoogt het runtime-patchnummer. SDK-patch verhoogt het laatste cijfer van de SDK-versie.
Wijziging van SDK-functie 5.0.1 5.0.200 De runtime-patch is niet gewijzigd. Door de nieuwe SDK-functie wordt het eerste cijfer in de SDK-versie verhoogd.
Runtimepatch 5.0.2 5.0.200 De runtime-patch verhoogt het runtime-patchnummer. SDK verandert niet.

In de voorgaande tabel ziet u verschillende beleidsregels:

  • De runtime en SDK delen primaire en secundaire versies. De eerste twee getallen voor een bepaalde SDK en runtime moeten overeenkomen. Alle voorgaande voorbeelden maken deel uit van de .NET 5.0-releasestream.
  • De patchversie van de runtime wordt alleen vernieuwd wanneer de runtime wordt bijgewerkt. Het SDK-patchnummer wordt niet bijgewerkt voor een runtimepatch.
  • De patchversie van de SDK wordt alleen bijgewerkt wanneer de SDK wordt bijgewerkt. Het is mogelijk dat voor een runtime-patch geen SDK-patch is vereist.

OPMERKINGEN:

  • Als de SDK 10 onderdelenupdates heeft vóór een runtime-onderdelenupdate, worden versienummers in de 1000-serie meegerold. Versie 5.0.1000 volgt versie 5.0.900. Deze situatie wordt niet verwacht.
  • 99 patchreleases zonder een functierelease worden niet uitgevoerd. Als het aantal van een release dit getal nadert, wordt er automatisch een functierelease uitgevoerd.

Meer informatie vindt u in het eerste voorstel in de opslagplaats dotnet/ontwerpen .

Semantisch versiebeheer

De .NET Runtime voldoet ruwweg aan Semantic Versioning (SemVer), waarbij het gebruik van MAJOR.MINOR.PATCH versiebeheer wordt gebruikt, waarbij de verschillende onderdelen van het versienummer worden gebruikt om de mate en het type wijziging te beschrijven.

MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]

De optionele PRERELEASE en BUILDNUMBER onderdelen maken nooit deel uit van ondersteunde releases en bestaan alleen in nightly builds, lokale builds van broncode, en niet-ondersteunde preview-releases.

Wijzigingen in runtime-versienummer

  • MAJOR wordt één keer per jaar verhoogd en kan het volgende bevatten:

    • Belangrijke wijzigingen in het product of een nieuwe productrichting.
    • API heeft belangrijke wijzigingen geïntroduceerd. Er is een hoge drempel voor het accepteren van ingrijpende wijzigingen.
    • Er wordt een nieuwere MAJOR versie van een bestaande afhankelijkheid gebruikt.

    Grote releases vinden eenmaal per jaar plaats, even genummerde versies zijn langetermijn-ondersteunde (LTS)-releases. De eerste LTS-release met dit versiebeheerschema is .NET 6. De nieuwste niet-LTS-versie is .NET 9.

  • MINOR wordt verhoogd wanneer:

    • Er wordt een openbaar API-oppervlak toegevoegd.
    • Er wordt een nieuw gedrag toegevoegd.
    • Er wordt een nieuwere MINOR versie van een bestaande afhankelijkheid gebruikt.
    • Er wordt een nieuwe afhankelijkheid geïntroduceerd.

  • PATCH wordt verhoogd wanneer:

    • Er zijn oplossingen voor fouten aangebracht.
    • Ondersteuning voor een nieuwer platform wordt toegevoegd.
    • Er wordt een nieuwere PATCH versie van een bestaande afhankelijkheid gebruikt.
    • Een andere wijziging past niet in een van de vorige gevallen.

Wanneer er meerdere wijzigingen zijn, wordt het hoogste element dat wordt beïnvloed door afzonderlijke wijzigingen verhoogd en worden de volgende opnieuw ingesteld op nul. Wanneer MAJOR bijvoorbeeld wordt verhoogd, MINOR.PATCH wordt deze waarde opnieuw ingesteld op nul. Wanneer MINOR wordt verhoogd, PATCH wordt de waarde opnieuw ingesteld op nul, terwijl MAJOR dit hetzelfde blijft.

Versienummers in bestandsnamen

De bestanden die voor .NET zijn gedownload, bevatten de versie, bijvoorbeeld dotnet-sdk-5.0.301-win-x64.exe.

Preview-versies

Preview-versies hebben een -preview.[number].[build] toegevoegd aan het versienummer. Bijvoorbeeld: 6.0.0-preview.5.21302.13.

Onderhoudsversies

Nadat een release is uitgegaan, stoppen de releasebranches in het algemeen met het produceren van dagelijkse builds en beginnen ze in plaats daarvan met het produceren van onderhoudsversies. Bij onderhoudsversies is er een -servicing-[number] toegevoegd aan de versie. Bijvoorbeeld: 5.0.1-servicing-006924.

.NET Runtime-compatibiliteit

De .NET Runtime onderhoudt een hoog compatibiliteitsniveau tussen versies. .NET-apps zouden in grote lijnen moeten blijven werken na een upgrade naar een nieuwe belangrijke .NET Runtime-versie.

Elke belangrijkste .NET Runtime-versie bevat opzettelijke, zorgvuldig gecontroleerde en gedocumenteerde brekende wijzigingen. De gedocumenteerde belangrijke wijzigingen zijn niet de enige bron van problemen die van invloed kunnen zijn op een app na de upgrade. Een prestatieverbetering in .NET Runtime (die niet wordt beschouwd als een wijziging die fouten veroorzaakt) kan bijvoorbeeld latent-app-threadingfouten blootstellen die ervoor zorgen dat de app niet in die versie werkt. Het is verwacht dat voor grote apps een paar fixes nodig zijn na een upgrade naar een nieuwe primaire .NET Runtime-versie.

.NET-apps zijn standaard geconfigureerd om te worden uitgevoerd op een bepaalde primaire .NET Runtime-versie, dus hercompilatie wordt ten zeerste aanbevolen om de app te upgraden om uit te voeren op een nieuwe primaire .NET Runtime-versie. Test vervolgens de app opnieuw na een upgrade om eventuele problemen te identificeren.

Stel dat een upgrade via app-hercompilatie niet haalbaar is. In dat geval biedt .NET Runtime aanvullende instellingen om een app in staat te stellen om te worden uitgevoerd op een hogere primaire .NET Runtime-versie dan de versie waarvoor deze is gecompileerd. Met deze instellingen worden de risico's voor het upgraden van de app naar een hogere primaire .NET Runtime-versie niet gewijzigd en is het nog steeds vereist om de app na de upgrade opnieuw te testen.

De .NET Runtime ondersteunt het laden van bibliotheken die zijn gericht op oudere .NET Runtime-versies. Een app die is bijgewerkt naar een nieuwere primaire .NET Runtime-versie, kan verwijzen naar bibliotheken en NuGet-pakketten die gericht zijn op oudere .NET Runtime-versies. Het is niet nodig om tegelijkertijd de doelruntimeversie van alle bibliotheken en NuGet-pakketten waarnaar wordt verwezen door de app, te upgraden.

Zie ook

  • Last updated on