Comment .NET est versionné

2025-06-20

Le runtime .NET et le Kit de développement logiciel (SDK) .NET ajoutent de nouvelles fonctionnalités à différentes fréquences. En général, le Kit de développement logiciel (SDK) est mis à jour plus fréquemment que le runtime. Cet article explique le runtime et les numéros de version du Kit de développement logiciel (SDK).

.NET publie une nouvelle version majeure tous les mois de novembre. Les versions à numéros pairs, telles que .NET 6 ou .NET 8, sont prises en charge à long terme (LTS). Les versions LTS bénéficient d'une assistance et de correctifs gratuits pendant trois ans. Les versions impaires bénéficient d’un support standard. Les versions de support à terme standard bénéficient d’un support gratuit et de correctifs pendant 18 mois.

Informations détaillées sur la gestion des versions

Le runtime .NET adopte une approche de type majeur/mineur/correctif de la gestion de versions qui adhère à la gestion sémantique de versions.

Toutefois, le Kit de développement logiciel (SDK) .NET ne suit pas le contrôle de version sémantique. Le Kit de développement logiciel (SDK) .NET publie plus rapidement et ses numéros de version doivent communiquer à la fois le runtime aligné et les versions mineures et correctives du Kit de développement logiciel (SDK).

Les deux premières positions du numéro de version du Kit de développement logiciel (SDK) .NET correspondent à la version du runtime .NET avec qui elle a été publiée. Chaque version du Kit de développement logiciel (SDK) peut créer des applications pour ce runtime ou toute version inférieure.

La troisième position du numéro de version du Kit de développement logiciel (SDK) communique à la fois le numéro secondaire et le numéro de correctif. La version mineure est multipliée par 100. Les deux derniers chiffres représentent le numéro du correctif. La version mineure 1, la version 2 du correctif serait représentée sous la forme 102. Par exemple, voici une séquence possible de numéros de version du runtime et du SDK :

Changez	Runtime .NET	SDK .NET (*)	Remarques
Version initiale	5.0.0	5.0.100	Version initiale.
Correctif du Kit de développement logiciel (SDK	5.0.0	5.0.101	Le runtime n’a pas changé avec ce correctif sdk. Le correctif de SDK modifie le dernier chiffre dans le correctif de SDK.
Correctif de l'environnement d'exécution et du SDK	5.0.1	5.0.102	Le correctif du runtime modifie le numéro de correctif du runtime. Le correctif de SDK modifie le dernier chiffre dans le correctif de SDK.
Modification des fonctionnalités du Kit de développement logiciel (SDK)	5.0.1	5.0.200	Le correctif du runtime n’a pas changé. La nouvelle fonctionnalité SDK modifie le premier chiffre du correctif de SDK.
Correctif du runtime	5.0.2	5.0.200	Le correctif du runtime modifie le numéro de correctif du runtime. Le Kit de développement logiciel (SDK) ne change pas.

Dans le tableau précédent, vous pouvez voir plusieurs stratégies :

Le runtime et le SDK partagent des versions majeures et mineures. Les deux premiers nombres d’un KIT de développement logiciel (SDK) et d’un runtime donnés doivent correspondre. Tous les exemples précédents font partie du flux de publication .NET 5.0.
La version du correctif du runtime augmente uniquement lorsque le runtime est mis à jour. Le numéro de correctif du Kit de développement logiciel (SDK) ne se met pas à jour pour un correctif d’exécution.
La version corrective du Kit de développement logiciel (SDK) est mise à jour uniquement lorsque le Kit de développement logiciel (SDK) est mis à jour. Il est possible qu’un correctif d’exécution ne nécessite pas de correctif sdk.

REMARQUES :

Si le Kit de développement logiciel (SDK) a 10 mises à jour de fonctionnalités avant une mise à jour de fonctionnalité d’exécution, les numéros de version sont ajoutés à la série 1000. La version 5.0.1000 suit la version 5.0.900. Cette situation n’est pas censée se produire.
Il ne se produira pas 99 publications de correctifs sans une publication de fonctionnalité. Si une publication est proche de ce numéro, cela force une publication de fonctionnalité.

Vous pouvez voir plus de détails dans la proposition initiale dans le dépôt dotnet/designs .

Gestion sémantique de version

Le runtime .NET respecte approximativement le contrôle de version sémantique (SemVer) en adoptant l’utilisation du MAJOR.MINOR.PATCH contrôle de version, en utilisant les différentes parties du numéro de version pour décrire le degré et le type de modification.

MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]

Les composants facultatifs PRERELEASE et BUILDNUMBER ne font jamais partie des versions supportées et existent uniquement sur les builds nocturnes, les builds locaux à partir de sources cibles et les versions préliminaires non supportées.

Modifications du numéro de version du runtime

MAJOR est incrémenté une fois par an et peut contenir :
- Changements significatifs dans le produit ou dans une nouvelle direction de produit.
- L’API a introduit des modifications cassantes. La barre est haute pour accepter les changements cassants.
- Une version plus récente MAJOR d’une dépendance existante est adoptée.
Les versions majeures se produisent une fois par an et les versions numérotées paires sont des versions prises en charge à long terme (LTS). La première version LTS utilisant ce schéma de contrôle de version est .NET 6. La dernière version non-LTS est .NET 9.
MINOR est incrémenté lorsque :
- La surface de l'API publique est augmentée.
- Un nouveau comportement est ajouté.
- Une version plus récente MINOR d’une dépendance existante est adoptée.
- Une nouvelle dépendance est introduite.
PATCH est incrémenté lorsque :
- Des correctifs de bogues sont effectués.
- Le support pour une plateforme plus récente est intégré.
- Une version plus récente PATCH d’une dépendance existante est adoptée.
- Toute autre modification ne correspond pas à l’un des cas précédents.

Lorsqu’il existe plusieurs modifications, l’élément le plus élevé affecté par les modifications individuelles est incrémenté et les éléments suivants sont réinitialisés à zéro. Par exemple, lorsqu'MAJOR est incrémenté, MINOR.PATCH sont réinitialisés à zéro. Lorsqu'il MINOR est incrémenté, PATCH est réinitialisé à zéro, tandis que MAJOR reste inchangé.

Numéros de version dans les noms de fichiers

Les fichiers téléchargés pour .NET portent la version, par exemple dotnet-sdk-5.0.301-win-x64.exe.

Préversion des versions

Les versions en préversion ont un -preview.[number].[build] ajouté au numéro de version. Par exemple : 6.0.0-preview.5.21302.13.

Versions de maintenance

Une fois qu’une version est sortie, les branches de mise en production arrêtent généralement de produire des builds quotidiennes et commencent plutôt à produire des builds de maintenance. Les versions de maintenance ont un -servicing-[number] suffixe à la fin de la version. Par exemple : 5.0.1-servicing-006924.

Compatibilité du runtime .NET

Le runtime .NET gère un niveau élevé de compatibilité entre les versions. Les applications .NET doivent continuer à fonctionner après la mise à niveau vers une nouvelle version majeure du runtime .NET.

Chaque version principale du runtime .NET contient des modifications intentionnelles, soigneusement vérifiées et documentées. Les changements disruptifs documentés ne constituent pas la seule source de problèmes pouvant affecter une application après la mise à jour. Par exemple, une amélioration des performances dans le runtime .NET (qui n’est pas considérée comme une modification cassante) peut exposer des bogues de thread d’application latents qui entraînent l’arrêt de l’application sur cette version. Il est prévu que les applications volumineuses nécessitent quelques correctifs après la mise à niveau vers une nouvelle version majeure du runtime .NET.

Par défaut, les applications .NET sont configurées pour s’exécuter sur une version principale .NET Runtime donnée. Par conséquent, la recompilation est vivement recommandée pour mettre à niveau l’application pour qu’elle s’exécute sur une nouvelle version principale du runtime .NET. Puis retestez l’application après la mise à niveau pour identifier les problèmes.

Supposons que la mise à niveau via la recompilation d’application n’est pas réalisable. Dans ce cas, le runtime .NET fournit des paramètres supplémentaires pour permettre à une application de s’exécuter sur une version majeure du runtime .NET supérieure à la version pour laquelle elle a été compilée. Ces paramètres ne modifient pas les risques liés à la mise à niveau de l’application vers une version majeure du runtime .NET, et il est toujours nécessaire de retester l’application après la mise à niveau.

Le runtime .NET prend en charge le chargement des bibliothèques qui ciblent les anciennes versions du runtime .NET. Une application mise à niveau vers une version majeure du runtime .NET plus récente peut référencer des bibliothèques et des packages NuGet qui ciblent des versions plus anciennes du runtime .NET. Il n’est pas nécessaire de mettre à niveau simultanément la version du runtime cible de toutes les bibliothèques et packages NuGet référencés par l’application.

Partager via