Desenvolvedores reclamam que suporte longo do .NET não dura o suficiente

A política de suporte da Microsoft para o .NET voltou a ser questionada por desenvolvedores que consideram curto demais o ciclo de vida das versões LTS da plataforma. A discussão foi reacendida em uma issue aberta no repositório oficial do .NET no GitHub, na qual um desenvolvedor argumenta que a janela atual de suporte não acompanha o ritmo real de adoção e atualização de ambientes corporativos.

O .NET moderno, anteriormente conhecido como .NET Core, segue um modelo de grandes lançamentos anuais. As versões pares são classificadas como LTS, sigla para Long-Term Support, e recebem suporte por três anos. Já as versões ímpares têm suporte por dois anos. Na prática, isso cria um ciclo previsível para a Microsoft, mas pode gerar pressão significativa para empresas que mantêm aplicações críticas em produção.

A principal crítica é que, quando uma nova versão LTS é lançada, a versão LTS anterior já consumiu dois dos seus três anos de suporte. Isso deixa, na prática, apenas cerca de um ano para empresas planejarem, testarem e concluírem a migração antes do fim do ciclo de vida. Para fornecedores de software, o problema também afeta a percepção de clientes, que podem hesitar em adotar produtos baseados em uma versão próxima do fim de suporte.

Um desenvolvedor comentou na discussão que sua telemetria mostra aproximadamente 50% das versões implantadas de seu software rodando em versões EOL, ou seja, que já chegaram ao fim de vida. Ele também criticou a janela de atualização de apenas um ano entre versões LTS e afirmou tentar usar o .NET Framework sempre que possível, por causa do suporte mais longo atrelado ao ciclo de vida do Windows.

O .NET Framework, versão legada e restrita ao Windows, está em modo de manutenção e é tratado como um componente do sistema operacional. Por isso, recebe suporte por períodos muito mais longos. Em contrapartida, é uma plataforma antiga, com menor evolução e suporte cada vez mais limitado no ecossistema moderno. Muitas bibliotecas e frameworks já não oferecem compatibilidade com ele, incluindo o ASP.NET Core da própria Microsoft.

Esse contraste coloca empresas em uma posição difícil. O .NET moderno oferece mais recursos, compatibilidade multiplataforma, melhorias de performance e maior alinhamento com o ecossistema atual. Mas seu ciclo de suporte exige atualizações mais frequentes. Já o .NET Framework oferece previsibilidade e suporte prolongado, mas perde relevância técnica e compatibilidade com bibliotecas atuais.

A reclamação não é nova. Em uma discussão semelhante aberta em 2023, Richard Lander, gerente de programa da Microsoft, afirmou que a empresa escolheu os prazos de suporte buscando equilibrar tempo estável de implantação para usuários e capacidade da equipe de continuar inovando. Segundo ele, a Microsoft chegou a discutir janelas de suporte mais longas e ofertas pagas de suporte estendido, mas optou por manter apenas o plano gratuito.

A comparação com outras plataformas reforça a crítica de parte da comunidade. O suporte gratuito da Microsoft para versões LTS do .NET é menor do que o oferecido por algumas tecnologias concorrentes. O Java, por exemplo, costuma contar com cinco anos de suporte para versões LTS, além de opções de suporte estendido. O Python oferece cinco anos de correções de segurança para todos os lançamentos.

Embora a atualização entre versões do .NET possa ser simples em alguns casos, ambientes corporativos raramente dependem apenas do runtime. A migração pode envolver mudanças incompatíveis, atualização de dependências de terceiros, adaptação de bibliotecas, ciclos formais de testes, homologação, janela de implantação, documentação, treinamento e, em alguns casos, contratação de desenvolvedores externos.

Um comentário em uma discussão de 2023 resumiu o problema sob a ótica de custo. Segundo o participante, o .NET Framework gera despesas principalmente com modificações funcionais e correções de bugs, enquanto o .NET moderno adiciona a esse cenário o custo recorrente de upgrades de versão em intervalos relativamente curtos.

A questão também aparece em decisões sobre bibliotecas mantidas pela Microsoft. Em março, Shay Rojansky, principal software engineer da empresa, pediu feedback sobre a possibilidade de remover suporte ao .NET Framework na biblioteca Microsoft.Data.Sqlite. Um comentário afirmou que, atualmente, .NET Standard 2.0 e .NET Framework 4.8 são os únicos alvos .NET com prazos de suporte considerados razoáveis para empresas.

O .NET Standard 2.0 define um conjunto comum de APIs implementado tanto pelo .NET Framework quanto por versões modernas do .NET, incluindo o .NET 10. Apesar de Rojansky ter considerado o comentário fora do tema principal da issue, a observação mostra como o ciclo de suporte ainda influencia decisões técnicas de compatibilidade em bibliotecas, produtos e aplicações empresariais.

A proposta de remover suporte ao .NET Framework na Microsoft.Data.Sqlite acabou encerrada como “not planned”. Embora a decisão não tenha sido atribuída diretamente à discussão sobre suporte corporativo, o episódio ilustra por que o .NET Framework continua presente em muitas organizações: não necessariamente por preferência técnica, mas por estabilidade percebida e previsibilidade de ciclo de vida.

Para a Microsoft, janelas mais curtas ajudam a concentrar esforço de engenharia em versões recentes, reduzir complexidade de manutenção e acelerar a evolução da plataforma. Para empresas, porém, cada upgrade representa risco operacional, custo e esforço de validação. Esse desalinhamento entre ritmo de inovação e ritmo corporativo de adoção é o centro da reclamação.

O debate tende a continuar à medida que o .NET Framework envelhece e o ecossistema moderno avança. Quanto mais bibliotecas abandonarem suporte à plataforma legada, maior será a pressão para migrar. Ao mesmo tempo, se o ciclo LTS do .NET moderno continuar sendo visto como curto, muitas empresas podem permanecer presas a versões antigas ou operar por longos períodos em versões já fora de suporte.