Разработчики раскритиковали трёхлетний срок LTS-поддержки платформы .NET от Microsoft

Разработчик заново поднял многолетний спор о политике поддержки платформы .NET от Microsoft, открыв новый issue на GitHub с аргументом, что трёхлетнее окно долгосрочной поддержки слишком короткое для циклов обновления корпоративных систем.

Как устроена текущая модель поддержки .NET

Действующая схема Microsoft делит релизы .NET на два типа по сроку поддержки, и именно эта схема стала предметом жалобы:

• чётные версии .NET получают три года бесплатной долгосрочной поддержки (LTS)
• нечётные версии считаются стандартными релизами (STS) и поддерживаются всего 18 месяцев
• именно трёхлетнее окно для LTS-версий разработчик считает недостаточным для крупных предприятий
• спор не новый — жалоба на такую политику поднимается повторно, теперь через новый issue на GitHub, а не впервые

Почему предприятия недовольны циклом обновлений

Крупные организации обычно проходят внутренние циклы тестирования, согласования и постепенного развёртывания новых версий платформ по всей инфраструктуре — от отдельных сервисов до legacy-систем, от которых зависит бизнес, — и эти циклы редко укладываются в три года. Когда окно поддержки заканчивается раньше, чем компания успевает завершить переход на новую LTS-версию, IT-отделы вынуждены либо ускорять миграцию за счёт качества тестирования, либо оставаться на версии без официальной поддержки и патчей безопасности, что создаёт риск для всей инфраструктуры.

Именно этот разрыв между темпом релизов Microsoft и реальной скоростью обновления корпоративных систем и стал поводом для нового обращения на GitHub. Автор issue указывает, что подобные жалобы от сообщества разработчиков корпоративного софта звучат не первый год, но модель поддержки платформы принципиально не менялась.

Что предлагают изменить

Хотя конкретных встречных предложений Microsoft по итогам жалобы пока нет, сам факт повторного всплеска дискуссии в публичном issue на GitHub показывает, что действующая асимметричная модель поддержки — три года для чётных версий и полтора года для нечётных — остаётся источником трения между темпом разработки платформы и практикой её внедрения в больших организациях.

Чем это отличается от других платформ

Асимметричная схема поддержки — короткий цикл для одних версий и длинный для других — не уникальна для .NET, но именно у Microsoft она регулярно вызывает нарекания со стороны разработчиков, которые обслуживают крупные корпоративные системы. Компании, у которых миграция между мажорными версиями требует согласования с десятками внутренних команд, тестирования интеграций и постепенного раскатывания по продакшену, часто физически не укладываются в трёхлетнее окно, даже если начинают подготовку заранее.

Для таких организаций разница между 18 месяцами и тремя годами поддержки — это не техническая деталь, а вопрос бюджета: продление поддержки устаревшей версии вручную или экстренная миграция обходятся дороже, чем спокойный переход по плану.

Что могло бы решить проблему

Разработчик, поднявший тему в новом issue, аргументирует свою позицию именно циклом обновлений крупных организаций, а не удобством отдельных разработчиков. Возможные пути решения, которые обсуждаются в подобных спорах вокруг LTS-политик программных платформ, обычно сводятся к нескольким вариантам: увеличить окно поддержки для LTS-версий, ввести отдельный расширенный платный тариф поддержки для корпоративных клиентов или синхронизировать релизный цикл с типичными циклами закупок и бюджетирования в крупных компаниях. Какой из этих вариантов рассмотрит Microsoft — из открытого материала не следует, реакции компании на конкретный issue пока не сообщается.

Что это значит

Спор о сроках LTS-поддержки .NET — не разовая жалоба, а повторяющаяся тема в сообществе разработчиков корпоративного софта. Пока Microsoft сохраняет модель «три года для чётных версий, 18 месяцев для нечётных», компаниям с длинными циклами обновления придётся закладывать риск устаревшей поддержки в свои планы миграции — либо продолжать добиваться пересмотра политики через публичные каналы вроде GitHub.