Publié le 29/06/2023
Par Christophe MOMMER
Avant de commencer ce billet, un peu de contexte et de vocabulaire. Dans ce billet :
- STS = Short Term Support = version courante
- LTS = Long Term Support = version long terme
Ensuite, il ne s'agit que d'un avis personnel basé sur mes réflexions et mes expérimentations, au regard des questions qui se posent sur "quelle version de .NET choisir pour mon projet d'entreprise". Cette question ne se pose généralement pas trop pour les projets personnels ou de faible ampleur, mais se pose plus en entreprise, d'où ce billet.
Reprenons les fondamentaux
Avant l'arrivée de .NET Core, le cycle de publication du framework .NET, tout comme celui de Visual Studio, était branché sur le fonctionnement à l'ancienne des Service Pack pour Windows (pour ceux qui ont connu). Le principe : une grosse mise à jour tous les X mois. Sauf que ce mode de déploiement des mises à jour, dans le fonctionnement ultra-connecté moderne, n'a plus de sens. Autant à l'époque de Windows XP, Microsoft envoyait encore des CD par la poste qui contenait le SP2 de Windows XP car des gens n'avait qu'une connexion 56k (seuls les plus anciens reconnaitront), autant aujourd'hui, l'ADSL est le minimum syndical, et la fibre est bien installée.
De ce fait, ce fonctionnement en "grosses mise à jour" est totalement inutile et dépassé. Au lieu de ça, il est préférable d'être + "devops" et de faire des maj, petites mais constantes.
Microsoft a mis quelques temps à trouver son rythme de publication avec .NET Core. On est passé de la version 1.0 à 1.1, puis 2.0, 2.1 (qui est une LTS) à 2.2 (qui paradoxalement ne l'est pas...) à .NET Core 3.0 (pas une LTS) pour finir sur .NET Core 3.1 (youhou, une LTS !), et là, ils se sont dis : il est temps de faire du ménage et d'avoir une ligne directrive plus claire.
Le calendrier, audacieux, des équipes .NET c'est : une version majeure par an (en commençant avec .NET 5, parce que .NET 4 ferait trop penser à .NET Framework 4.x et créerait encore plus de confusion) publiée en novembre.
Le challenge du versionning
Avec ce calendrier, Microsoft doit assurer sur plusieurs plans : fournir une version qui sera supportée pendant + d'un an pour que le cycle de MAJ de certaines entreprises puissent se caler dessus, et inversement, proposer des versions "court-terme" (supportée 1 an 1/2) où Microsoft pourra quand même innover (ça servira de toute façon pour la prochaine LTS) et avoir un public d'early adopters.
Dit comme ça, on a l'impression que : les LTS sont pour les entreprises et ont été "beta-testées" par les early adopter de la LTS-1. En gros, si .NET 6 est LTS et fonctionne bien, c'est parce que des gens (pro ou pas) ont utilisé .NET 5 et ont essuyés les plâtres... Mais est-ce réellement ça ?
Mon expérience
Microsoft a toujours mis un point d'honneur, jusqu'à présent, que la mise à jour d'une version X à X+1, dans l'ecosystème .NET se fasse de la façon la plus fluide et simple possible. En gros, un changement dans le csproj et on part sur le nouveau runtime et le nouveau SDK.
Bien entendu, avec un projet de l'ampleur de .NET en général, il est tout simplement IMPOSSIBLE de ne pas introduire de changements cassants quand on veut innover. D'où, cela est systématiquement documenté (par exemple, pour .NET 6 vers .NET 7, c'est ici)
Mais du coup, la documentation des breaking changes est pour une migration de la version N-1 vers N, donc par exemple, de .NET 6 à .NET 7, et non pas de .NET 6 à .NET 8 (donc de LTS à LTS ...). De ce fait, je suis largement partisan de migrer vers la nouvelle version majeure, peu importe sa durée de support, tout simplement pour bénéficier des dernières innovations mais aussi car cette étape de migration me préparer le terrain pour la version suivante, car je répare d'un coup mes breaking changes (qui, disons le, sont très peu nombreux...).
Donc, quid des sociétés qui ne veulent que de la LTS ?
Définissions ce qu'est "long terme"
Quand Microsoft publie .NET en LTS, le cycle de support est de 3 ans après la publication. Attention sur ces 3 ans de support, il ne s'agit absolument que de bug-fix critiques ou de failles de sécurité. Tout ce qui est nouveau en terme de méthodes dans le framework ou d'améliorations de performances sont arrivés avec la RTM (version initiale) et seront ajoutés à la prochaine version.
En bref, ce qui rassure les entreprises, c'est d'avoir 3 ans de "tranquilité" car pas de breaking changes ni de nouvelles choses qui pourraient bousculer les habitudes. C'est une stratégie, mais ça fait passer l'équipe et le produit à côté de grosses innovations.
Ensuite, quand il y a une publication d'une STS, le cycle de support est d'1 an et demi après la publication.
Concrètement, Microsoft l'illustre avec ce schéma (tiré du site officiel) :
Ce que j'en retire, personnellement, c'est que la fin de vie d'une STS et d'une LTS se joue dans un mouchoir de poche. Par exemple, la fin de vie de .NET 6 arrive en novembre 2024 (donc à la sortie de .NET 9) et la fin de vie de .NET 7 arrive en mai 2024. Cela n'est donc que 6 mois de décalage.
Si on joue la carte LTS à fond, ça veut dire qu'alors que .NET 9 sera sorti, les équipes devront travailler pour migrer le projet vers .NET 8, en fixant les éventuels problèmes de migration de .NET 6 -> .NET 7 puis .NET 7 -> .NET 8. Alors que si la version .NET 7 avait été adoptée proche de sa release (je conseille, pour les entreprises, d'attendre 1 ou 2 mois après la RTM), et idem pour .NET 8, la quantité de travail est non seulement moindre (une seule version à migrer) et l'innovation technique est directement dans le produit.
En bref, je peux comprendre que ça ait un côté "rassurant" de se dire que pendant 3 ans, on est sur une version .NET supportée, mais pour avoir recroisé cela avec nombre de développeurs, beaucoup préfèrent être sur les dernières versions et profiter des dernières innovations pour leurs développements quotidiens. Le risque n'étant pas énorme, je fais cela pour ma plateforme de façon systématique et aussi dans les entreprises où j'interviens et où j'ai une totale liberté d'action.
