Linux 7.2 encerra manutenção: inventarie suporte, não só versões
O fim da série 7.2 upstream pede uma decisão de suporte. A versão do kernel, isoladamente, não diz quem continua entregando correções.
Greg Kroah-Hartman anunciou o Linux 7.2.15 como a última versão da série estável 7.2.y e orientou seus usuários a migrar para 7.3.y, segundo a LWN.[4] O encerramento trata da manutenção upstream dessa árvore, não determina por si só o prazo de suporte de cada distribuição ou fornecedor.[4]
Para quem desenvolve e opera software, a pergunta útil não é apenas qual número aparece no kernel. É quem entrega correções para aquele pacote, sob qual política e até quando.
O que muda para quem desenvolve
A justificativa apresentada para antecipar um pouco o encerramento foi operacional: calendário e fila de patches levariam à manutenção simultânea de oito branches, esforço considerado excessivo.[4] A notícia mostra uma decisão de capacidade de manutenção, não um anúncio de incompatibilidade generalizada das aplicações.
Minha leitura é que esse tipo de aviso deveria alimentar o inventário de dependências operacionais. Se a equipe acompanha diretamente a árvore upstream, a orientação publicada é mudar para uma série mantida.[4] Se usa um pacote de fornecedor, eu exigiria uma confirmação da política daquele pacote antes de classificar a máquina como sem suporte.
Não faria uma atualização ampla baseada apenas em comparação numérica. Prefiro uma decisão que relacione origem do pacote, evidência de manutenção, dependências relevantes e possibilidade de retorno. O aviso é um gatilho para investigar, não um diagnóstico completo de cada instalação.
Como aplicar
Monte uma ficha por ambiente com versão completa do pacote, origem, política de suporte consultada e data dessa consulta. Quando a informação não estiver disponível, marque suporte desconhecido e atribua um responsável pela confirmação. Evite preencher a lacuna com uma suposição otimista.
Para uma migração necessária, escolha um ambiente representativo e escreva critérios de aceitação antes de alterar qualquer coisa. Eu incluiria inicialização, rede, armazenamento, módulos necessários e execução de uma carga típica da aplicação. Compare com o ambiente anterior e preserve um procedimento de retorno que possa ser usado sem depender da máquina atualizada.
Uma aplicação web pode ter um roteiro próprio: inicializar suas dependências, executar chamadas representativas e observar erros e latência sob a mesma carga. Isso é uma proposta de validação local, não um resultado já obtido com Linux 7.3.
Cuidados e limites
A nota informa que a versão final contém um pequeno conjunto de atualizações, mas não detalha individualmente as correções.[4] Não há base nela para inventar uma lista de CVEs, afirmar exploração ativa ou prometer ganho de desempenho.
Também não se deve concluir que todo kernel identificado como 7.2 deixou de receber patches do distribuidor.[4] O trade-off é evitar tanto a permanência sem manutenção quanto uma migração desnecessária e apressada. Evidência de suporte e compatibilidade vale mais que uma regra baseada apenas em versão.
Fonte
[4] Fonte: LWN.net