Suporte a várias linhas de release: quais correções vão para onde

O que é

Uma política de versões suportadas responde à pergunta "a versão A.B vai receber esta correção?" antes que alguém a faça. Ela tem duas partes: uma tabela de linhas de release com seu status e suas datas, e regras de backport por classe de correção. O processo de release do Django é um exemplo enxuto: a branch main recebe novas funcionalidades; o último feature release recebe correções de bloqueadores de release (segurança, perda de dados, crashes, bugs graves em funcionalidades novas, regressões); correções de segurança e de perda de dados vão para a main, para as duas últimas branches de feature release e para qualquer branch de suporte de longo prazo (LTS) ainda suportada; correções de documentação são portadas com mais liberdade. A PEP 602 descreve a série do Python como mantida por cinco anos: releases de bugfix nos dois primeiros, depois releases de código-fonte somente de segurança por mais três (a partir do Python 3.13). O livro do Rust apresenta o extremo oposto: apenas a versão estável mais recente é suportada, de modo que cada versão tem suporte por seis semanas.

Por que importa

Os usuários não conseguem atualizar no ritmo do projeto, e quem mantém o código não consegue corrigir todas as linhas para sempre. Sem uma regra escrita, cada pedido de backport vira uma negociação, e as correções de segurança acabam entrando silenciosamente só na main, enquanto os usuários da linha anterior acreditam estar protegidos.

Como aplicar

• Publique a tabela onde os usuários costumam procurar: linha, status, primeiro release, fim de vida previsto. Mantenha uma branch por linha suportada, com nomes consistentes (o Django usa stable/A.B.x).
• Padrão para um projeto pequeno: o último feature release recebe todas as correções; o anterior recebe correções de segurança por um período declarado; nada além disso. Amplie apenas quando houver um segundo mantenedor.
• Faça o backport com cherry-pick, incluindo na mensagem a referência ao commit original, e publique um release com o backport; uma correção numa branch sem release não ajuda ninguém.
• Limite a matriz de CI às linhas suportadas; uma linha sem suporte que continua sendo testada atrai pedidos de correção.
• Anuncie o fim de vida com antecedência no changelog e retire a linha da tabela na data prevista.
• Ofereça suporte de longo prazo somente se for possível prometer de fato esses anos; um selo de LTS abandonado é pior que nenhum.

Armadilhas

Portar funcionalidades com o rótulo de correções, o que transforma uma linha estável em uma segunda linha de desenvolvimento. Corrigir um problema de segurança apenas na main. Deixar a matriz de CI crescer a cada versão suportada de cada dependência até que nada fique verde. Esquecer que a documentação das linhas antigas também precisa continuar acessível.