Les Développeurs ont Critiqué la Fenêtre de Support LTS de Trois Ans de Microsoft pour la Plateforme .NET

Un développeur a ravivé un différend de longue date concernant la politique de support de la plateforme .NET de Microsoft en ouvrant un nouveau problème GitHub arguant que la fenêtre de support à long terme de trois ans est trop courte pour les cycles de mise à jour des systèmes d'entreprise.

Comment fonctionne le modèle de support actuel de .NET

Le schéma actuel de Microsoft divise les versions .NET en deux types selon la durée du support, et ce schéma est devenu lui-même l'objet de plaintes :

• Les versions paires de .NET reçoivent trois ans de support à long terme gratuit (LTS)
• Les versions impaires sont considérées comme des versions standards (STS) et sont supportées pendant seulement 18 mois
• Le développeur estime que la fenêtre de trois ans pour les versions LTS est insuffisante pour les grandes entreprises
• Le différend n'est pas nouveau — les plaintes concernant cette politique sont à nouveau soulevées, maintenant via un nouveau problème GitHub, pas pour la première fois

Pourquoi les entreprises sont insatisfaites du cycle de mise à jour

Les grandes organisations suivent généralement des cycles internes de test, de coordination et de déploiement graduel de nouvelles versions de plate-formes dans toute leur infrastructure — des services individuels aux systèmes hérités dont l'activité dépend — et ces cycles s'inscrivent rarement dans trois ans. Quand la fenêtre de support se termine avant qu'une entreprise ne puisse terminer la transition vers une nouvelle version LTS, les départements informatiques sont forcés d'accélérer la migration au détriment de la qualité des tests, ou de rester sur une version sans support officiel et correctifs de sécurité, créant un risque pour toute l'infrastructure.

C'est précisément cet écart entre le rythme de sorties de Microsoft et la vitesse réelle de mise à jour des systèmes d'entreprise qui a motivé le nouvel appel sur GitHub. L'auteur du problème note que des plaintes similaires de la part de la communauté des développeurs de logiciels d'entreprise ont été entendues pendant des années, mais le modèle de support de la plateforme n'a pas fondamentalement changé.

Quels changements sont proposés

Bien qu'il n'y ait pas de propositions concrètes en retour de Microsoft suite à la plainte, le fait d'une discussion renouvelée dans un problème public GitHub montre que le modèle de support asymétrique actuel — trois ans pour les versions paires et 18 mois pour les impaires — reste une source de friction entre le rythme de développement de la plate-forme et sa pratique de mise en œuvre dans les grandes organisations.

En quoi cela diffère d'autres plates-formes

Le schéma de support asymétrique — un cycle court pour certaines versions et long pour d'autres — n'est pas unique à .NET, mais chez Microsoft il provoque régulièrement des plaintes de la part des développeurs qui maintiennent les grands systèmes d'entreprise. Les entreprises dont la migration entre versions majeures nécessite la coordination de dizaines d'équipes internes, des tests d'intégration et un déploiement graduel en production ne peuvent souvent pas respecter physiquement la fenêtre de trois ans, même s'ils commencent la préparation tôt.

Pour de telles organisations, la différence entre 18 mois et trois ans de support n'est pas un détail technique mais une question budgétaire : prolonger le support pour une version obsolète manuellement ou une migration d'urgence coûte plus cher qu'une transition planifiée.

Ce qui pourrait résoudre le problème

Le développeur qui a soulevé la question dans un nouveau problème GitHub argumente sa position en fonction des cycles de mise à jour des grandes organisations, pas de la commodité des développeurs individuels. Les solutions possibles discutées dans des différends similaires autour des politiques LTS pour les plates-formes logicielles se réduisent généralement à quelques options : prolonger la fenêtre de support pour les versions LTS, introduire un niveau de support étendu payant séparé pour les clients d'entreprise, ou aligner le cycle de sortie avec les cycles typiques d'approvisionnement et de budgétisation dans les grandes entreprises. Laquelle de ces options Microsoft envisagera n'est pas claire à partir des matériaux publics, et la réaction de l'entreprise au problème spécifique n'a pas encore été signalée.

Ce que cela signifie

Le différend concernant les délais de support LTS de .NET n'est pas une plainte isolée, mais un thème récurrent dans la communauté du développement de logiciels d'entreprise. Tant que Microsoft maintient le modèle de « trois ans pour les versions paires, 18 mois pour les impaires », les entreprises ayant des cycles de mise à jour longs devront tenir compte du risque d'un support obsolète dans leurs plans de migration — ou continuer à pousser pour une révision des politiques par le biais de canaux publics comme GitHub.