Linux publicou stable, LTS e rc no mesmo dia — são três decisões diferentes
A 9 de agosto chegaram 7.1.8, 6.18.44, 6.12.103, 6.6.151 e 7.2-rc7. Uma frota saudável segue o canal aprovado pela plataforma e pela distribuição, com canário e prova de runtime.
- Natureza
- Atualização operacional baseada no feed oficial Linux
- Data
- Versões publicadas em 9 de agosto de 2026 e verificadas em 11 de agosto
- Âmbito
- Frotas Linux; seguir suporte e empacotamento da distribuição usada
- Limite
- A publicação upstream não é uma instrução universal de instalação
Em resumo
O feed oficial do kernel regista em 9 de agosto Linux 7.1.8 como stable, três atualizações longterm e 7.2-rc7 como prepatch. A documentação explica que rc serve teste, stable recebe correções após a mainline e longterm prolonga manutenção de linhas selecionadas. A ação correta não é instalar a maior versão em todos os hosts: é reconciliar kernel upstream, pacote da distribuição, módulos, hardware, suporte, risco e política de cada serviço.
- Classifique cada host por canal permitido e fonte de pacote; upstream e distribuição não usam necessariamente o mesmo número ou calendário.
- Não leve 7.2-rc7 a produção geral; use ambientes de compatibilidade quando precisa antecipar regressões.
- Para stable/LTS, teste hardware, drivers externos, storage, rede e carga real antes de ampliar.
- Prove versão instalada e versão em execução; um reboot pendente deixa remediação incompleta.
Cinco versões no feed representam três estados de maturidade
O feed lista 7.1.8 como stable; 6.18.44, 6.12.103 e 6.6.151 como longterm; e 7.2-rc7 como mainline prepatch. A página de releases define rc como pré-lançamento para desenvolvimento e teste, stable como linha de correções após a release e longterm como manutenção prolongada de linhas escolhidas.
O processo upstream exige que correções stable já existam na mainline e sejam adequadas para backport, mas reconhece que regressões continuam possíveis. A distribuição pode adicionar backports, configurações e suporte próprios. Compare o pacote real, não apenas o número com kernel.org.
Canal antes da versão
- RCAntecipação
Executar em CI/hardware de teste para descobrir regressões antes da release final.
- STABLECorreção corrente
Avaliar 7.1.8 dentro da política da distribuição e do serviço.
- LTSManutenção prolongada
Aplicar a atualização da linha já aprovada, sem saltar de família por impulso.
- RUNTIMEProva final
Confirmar kernel ativo, módulos, serviço e caminho de rollback.
A matriz da frota deve ligar serviço, pacote e estado de boot
Registe família permitida, origem assinada, versão instalada, versão ativa, boot anterior disponível, módulos externos, live patches, taint, hardware e SLO. Agrupe por coortes que realmente partilham risco; duas VMs com kernels iguais podem ter drivers e workloads diferentes.
Promova com critérios observáveis: boot, erros de kernel, I/O, rede, latência, filas e testes funcionais. O rollback também altera estado; pode exigir reprocessar filas, reconstruir módulos ou restaurar configuração, por isso precisa de ensaio.
Decisão por canal
| Canal | Uso | Prova antes de promover | Não fazer |
|---|---|---|---|
| rc | Compatibilidade antecipada | CI e hardware de teste | Produção geral |
| stable | Correções correntes | Pacote, canário, SLO | Instalar fora da distribuição sem razão |
| longterm | Linha suportada | EOL, backport, módulos | Confundir LTS com ausência de risco |
| Distribuição | Contrato operacional | Advisory e assinatura | Comparar só número upstream |
| Runtime | Estado efetivo | Boot e serviço | Fechar com pacote apenas instalado |
Use 7.2-rc7 para aprender e as linhas aprovadas para corrigir
Envie rc7 para o laboratório que representa hardware e módulos futuros. Nas linhas stable e longterm já usadas, consuma o pacote aprovado pela distribuição, faça canário e mantenha o boot anterior até o período de observação fechar.
Um dashboard útil mostra divergências: pacote novo mas kernel antigo, kernel upstream sem origem aprovada, módulo que não compilou, host sem telemetria ou canário fora do SLO. É nessas diferenças que a atualização deixa de ser um número e passa a ser controlo operacional.
- Não misturar mudança de família com atualização corretiva sem necessidade.
- Não remover o kernel anterior antes de testar console e boot.
- Não usar ausência de alerta como prova de estabilidade.
- Registar tempo de observação e critérios de expansão por coorte.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01Linux kernel releases JSONkernel.org · SYS-LINUX
- 02Active kernel releaseskernel.org · SYS-LINUX
- 03How the Linux development process worksLinux Kernel documentation · SYS-LINUX
- 04Stable kernel rulesLinux Kernel documentation · SYS-LINUX
- 05Handling regressionsLinux Kernel documentation · SYS-LINUX
- 06Guide to Enterprise Patch Management PlanningNIST CSRC · CY-NISTCSRC
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.