Desenvolvedores criticam prazo de três anos do suporte LTS do .NET, da Microsoft

Um desenvolvedor reacendeu uma discussão antiga sobre a política de suporte da plataforma .NET, da Microsoft. Em uma nova issue no GitHub, ele argumenta que a janela de três anos de suporte de longo prazo é curta demais para os ciclos de atualização de sistemas corporativos.

Como funciona o modelo atual de suporte do .NET

O modelo atual da Microsoft divide as versões do .NET em dois tipos, conforme o prazo de suporte. É justamente esse modelo que motivou a reclamação:

• as versões pares do .NET recebem três anos de suporte de longo prazo (LTS) gratuito
• as versões ímpares são consideradas lançamentos padrão (STS) e têm suporte de apenas 18 meses
• o desenvolvedor considera insuficiente para grandes empresas justamente a janela de três anos das versões LTS
• a discussão não é nova: a reclamação contra essa política volta à tona, agora por meio de uma nova issue no GitHub, e não pela primeira vez

Por que as empresas estão insatisfeitas com o ciclo de atualizações

Grandes organizações costumam passar por ciclos internos de testes, aprovação e implantação gradual de novas versões de plataformas em toda a infraestrutura, de serviços isolados a sistemas legados dos quais o negócio depende. Esses ciclos raramente cabem em três anos. Quando o suporte termina antes de a empresa concluir a migração para a nova versão LTS, as equipes de TI precisam escolher: acelerar a migração e sacrificar a qualidade dos testes ou continuar em uma versão sem suporte oficial nem patches de segurança, o que coloca toda a infraestrutura em risco.

Foi exatamente esse descompasso entre o ritmo de lançamentos da Microsoft e a velocidade real de atualização dos sistemas corporativos que motivou a nova solicitação no GitHub. O autor da issue aponta que reclamações desse tipo vêm da comunidade de desenvolvedores de software corporativo há anos, mas o modelo de suporte da plataforma não mudou em sua essência.

O que se propõe mudar

Ainda não há contrapropostas concretas da Microsoft em resposta à reclamação. Mesmo assim, o simples fato de a discussão ressurgir em uma issue pública no GitHub mostra que o atual modelo assimétrico de suporte, com três anos para versões pares e um ano e meio para as ímpares, continua sendo fonte de atrito entre o ritmo de desenvolvimento da plataforma e a forma como ela é adotada em grandes organizações.

Como isso se compara a outras plataformas

O modelo assimétrico de suporte, com ciclo curto para algumas versões e longo para outras, não é exclusivo do .NET. Mas, no caso da Microsoft, ele gera queixas recorrentes de desenvolvedores que mantêm grandes sistemas corporativos. Empresas em que a migração entre versões principais exige alinhamento com dezenas de equipes internas, testes de integração e rollout gradual em produção muitas vezes simplesmente não conseguem cumprir a janela de três anos, mesmo quando começam a se preparar com antecedência.

Para essas organizações, a diferença entre 18 meses e três anos de suporte não é um detalhe técnico, e sim uma questão de orçamento: manter por conta própria uma versão desatualizada ou fazer uma migração emergencial sai mais caro do que uma transição tranquila e planejada.

O que poderia resolver o problema

O desenvolvedor que levantou o tema na nova issue fundamenta sua posição no ciclo de atualização das grandes organizações, e não na conveniência de desenvolvedores individuais. As soluções costumam aparecer em discussões semelhantes sobre políticas de LTS de plataformas de software e geralmente se resumem a algumas opções: ampliar a janela de suporte das versões LTS, criar um plano de suporte estendido pago para clientes corporativos ou sincronizar o ciclo de lançamentos com os ciclos típicos de compras e orçamento das grandes empresas. O material público não indica qual dessas opções a Microsoft vai considerar, e até o momento não há informação sobre uma resposta da empresa a essa issue específica.

O que isso significa

A discussão sobre os prazos de suporte LTS do .NET não é uma reclamação isolada, e sim um tema recorrente na comunidade de desenvolvedores de software corporativo. Enquanto a Microsoft mantiver o modelo de "três anos para versões pares, 18 meses para ímpares", empresas com ciclos de atualização longos terão de incluir em seus planos de migração o risco de ficar sem suporte, ou continuar pressionando por uma revisão da política em canais públicos como o GitHub.