Resumo

  • A entrada de um patch em uma versão estável é avaliada caso a caso; prolongar a manutenção de uma série antiga é uma decisão separada sobre capacidade.
  • O Kernel.org relaciona a duração do suporte às necessidades de quem usa as séries e à disponibilidade dos mantenedores. Uma data projetada de fim não é uma promessa comercial.

Um kernel antigo pode continuar útil a um dispositivo anos depois de seu lançamento. Isso não significa que qualquer correção proposta será incorporada à sua série estável, nem que ela terá manutenção enquanto o produto continuar à venda. O Linux tem duas barreiras distintas. Misturá-las transforma um rótulo útil em uma garantia que ninguém ofereceu.

A primeira barreira é aplicada a cada patch. As regras do kernel estável exigem que a correção, ou uma equivalente, já exista na linha principal. Ela deve ser claramente correta e testada, ter no máximo 100 linhas incluindo o contexto, seguir as regras de envio e resolver um problema real de usuário ou acrescentar um identificador de dispositivo. Entre os exemplos estão falhas, travamentos, corrupção de dados, problemas reais de segurança, peculiaridades de hardware e erros de compilação. As regras descartam riscos teóricos sem explicação de como poderiam ser explorados e mudanças sem benefício para o usuário. Esses limites facilitam a revisão de backports e reduzem o risco de introduzir outro defeito em uma série já usada. As regras do kernel estável descrevem os critérios e as formas de envio.

Passar por essa barreira não elimina a revisão. O processo documentado coloca os candidatos aceitos em uma fila, pede a análise de desenvolvedores e do mantenedor do subsistema afetado e testa o resultado em versões candidatas. Uma objeção pode retirar um patch da fila. O fato de a mudança ter passado antes pela linha principal comprova sua origem; não garante que todas as séries antigas receberão a correção automaticamente. Ela ainda precisa ser aplicável à versão de destino e resistir à revisão feita ali.

A segunda barreira define a vida útil da própria série. O Kernel.org descreve as versões de suporte prolongado como árvores antigas que recebem correções importantes, em geral com menos frequência do que as linhas estáveis ativas. Sua orientação cita grandes recursos novos, necessidades de distribuições comerciais, demanda de fabricantes de dispositivos, carga de trabalho e disponibilidade dos mantenedores como fatores de seleção. Uma nova série de longo prazo começa com uma data de fim projetada, que pode ser estendida se o interesse da indústria ajudar a sustentar a manutenção por mais tempo. A página diz que essa projeção não é fixa. A cópia consultada para este artigo mostra a data de 25 de fevereiro de 2026; sua explicação de política é útil, mas a lista de versões não representa a situação de outubro de 2026. A página de releases do Kernel.org descreve os fatores e as projeções.

O papel de Greg Kroah-Hartman é relevante sem torná-lo dono do sistema inteiro. A Linux Foundation o identifica como Fellow, mantenedor da série estável do Linux e de vários subsistemas. O documento sobre o processo de desenvolvimento lista Greg e Sasha Levin na equipe estável e descreve a participação dos mantenedores das áreas e dos revisores. Em uma entrevista de 2018, Greg contou que foi um dos desenvolvedores que se voluntariaram quando começaram os lançamentos estáveis, em 2005. Disse também que passou a manter mais séries simultâneas e associou esse trabalho à segurança de dispositivos em uso. É uma lembrança pessoal, não uma contagem atual de ramos nem prova de que ele escolhe sozinho cada série de longo prazo. O perfil da Linux Foundation, o processo de desenvolvimento do kernel e a entrevista de Greg delimitam esse papel.

Para um operador, essa diferença muda o que se pode concluir de um rótulo de suporte. Uma série de longo prazo do Kernel.org é uma linha mantida pela comunidade. Uma distribuição pode entregar um kernel baseado nela, acrescentar mudanças próprias ou manter outra árvore segundo seu calendário. O Kernel.org encaminha usuários de kernels de distribuição ao canal de suporte do fornecedor e avisa que desenvolvedores do kernel podem não oferecer suporte a essas compilações. O operador precisa descobrir quem mantém o kernel exato da imagem em produção, qual processo cobre correções de segurança e regressões, e se o compromisso do fornecedor alcança a vida útil do produto. O rótulo LTS, sozinho, não responde a essas questões contratuais. A FAQ do Kernel.org e sua página de releases distinguem esses limites.

O mecanismo econômico é simples, embora o número da versão possa escondê-lo. Cada série mantida por mais tempo exige trabalho: alguém precisa avaliar correções, conferir backports, testar lançamentos e responder quando surge uma regressão. As fontes públicas não medem essas horas nem seu custo. Elas mostram que a necessidade de quem usa o kernel e a disponibilidade dos mantenedores influenciam quais séries recebem atenção por mais tempo. A demanda da indústria pode justificar o esforço; não substitui as pessoas que precisam executá-lo.

A Nota 64 de Heng Lu oferece uma pergunta analítica útil: um documento de coordenação pode descrever um estado futuro sem torná-lo operacional por conta própria. Este artigo não diz que o Linux foi desenhado segundo aquela nota. Usada apenas como lente, a distinção ajuda a entender por que “longo prazo” e uma data projetada não são garantias autoexecutáveis. Eles descrevem um arranjo que precisa continuar sendo adotado e mantido. A Nota 64 é referência analítica, não evidência sobre a política do kernel.

Análise

As duas barreiras distribuem o risco em níveis diferentes. As regras de patch limitam o que entra em uma série existente; a seleção de versões de longo prazo limita quantas séries antigas a comunidade consegue continuar mantendo. Um filtro mais rigoroso não cria anos de capacidade de trabalho, e a demanda da indústria não torna seguro um backport sem revisão. O compromisso só existe enquanto tanto a correção quanto a capacidade de manter sua série permanecerem viáveis.

Esse horizonte depende de uma coalizão que pode mudar. Fabricantes de dispositivos podem precisar de kernels antigos para equipamentos já entregues; distribuições podem querer uma base estável; mantenedores precisam de tempo para revisar e testar o trabalho. As fontes públicas não mostram como essas contribuições são divididas nem quantificam o poder de negociação de cada participante. Elas indicam, porém, que a duração depende da demanda e do trabalho disponível, não apenas da idade do número da versão.

Fontes