Os ritmos de atualização variam significativamente entre os usuários do Kotlin. Algumas equipes atualizam sempre que uma nova versão é lançada sem pensar duas vezes, enquanto outras equipes em organizações regulamentadas seguem um ciclo multi-trimestral e tratam cada dependência como algo que precisa ser revisado, aprovado e então congelado em produção por algum tempo.
No meio de todas essas audiências, a adoção do Kotlin na JVM continua crescendo. Cerca da metade dos desenvolvedores de Kotlin hoje escreve aplicações para servidores, incluindo segmentos como infraestrutura de pagamentos e banco, onde algumas equipes já estão executando Kotlin em produção há anos. Uma grande parte das equipes nesses segmentos trabalha em ambientes onde todas as dependências de produção passam por uma revisão formal de segurança.
Em ambientes como esses, as equipes da plataforma se deparam com uma pergunta aparentemente simples: “Quais versões do Kotlin são suportadas?” Até hoje, não tínhamos uma resposta clara. Este post apresenta uma.
Crescimento da adoção significa garantias mais fortes de compatibilidade e segurança
A medida que mais código depende do Kotlin, a linguagem se torna mais útil – e mais restritiva. As pessoas que constroem sobre ela esperam que o que escreveram ontem continue funcionando amanhã, que as mudanças serão previsíveis e que a equipe por trás do Kotlin trate a compatibilidade como uma escolha deliberada em vez de um pensamento posterior.
Vários aspectos do Kotlin já funcionam dessa maneira. A estabilidade da linguagem no nível de código-fonte significa que o código escrito hoje continua compilando nas novas versões. Um ciclo de depreciação documentado substitui as mudanças inesperadas, então tudo que removemos é anunciado e os desenvolvedores recebem tempo para se adaptar. O Comitê de Linguagem é o corpo formal que aprova mudanças significativas na linguagem. E a biblioteca padrão carrega seu próprio contrato de compatibilidade em versões para APIs públicas.
Esses compromissos cresceram naturalmente à medida que o Kotlin se tornou uma parte estrutural de grandes bases de código. Cada um foi adicionado quando ficou claro que devíamos dar a garantia aos nossos usuários.
Mas uma coisa chave estava faltando dessa lista, especificamente uma resposta para a pergunta: “Por quanto tempo uma versão do Kotlin é suportada para corrigir problemas de segurança?” Para a maioria das equipes, essa lacuna é invisível. Mas existem organizações cujas revisões de dependências dependem da resposta – e para elas, essa lacuna é tudo.
Por que a falta de uma política de suporte era um problema
O modelo de lançamento do Kotlin é construído em torno de um ritmo constante de lançamentos estáveis. A versão mais recente e estável, seja uma versão da linguagem ou ferramentas, é a linha de base recomendada. Correções de bugs e desenvolvimento da linguagem fluem para o próximo lançamento em vez de retroceder através de patches. Para a maioria das equipes, isso funciona perfeitamente – atualizar é simples, e há pouco motivo para pensar sobre “suporte” como um conceito separado.
Para organizações que precisam de um sinal documentado de suporte, as consequências são concretas:
- Equipes de conformidade não podem listar o Kotlin como uma dependência suportada em seu processo padrão, pois não há data formal de fim do suporte para registrar.
- Cada nova versão do Kotlin em produção gera uma revisão individual de segurança ao invés de herdar um status de suporte documentado.
- Quadros de aquisição e avaliação de fornecedores pedem por documentação de fornecedor que não existe nesta forma.
- No caso de congelamentos da plataforma, a ausência de uma política significa “atualize imediatamente ou perca o suporte”. Este método não se encaixa na maneira como organizações gerenciam dependências.
A base de usuários do Kotlin continua crescendo e essa expansão inclui ambientes onde a ausência de uma resposta documentada carrega um custo real. Endereçar essa ausência é o próximo passo.
Introduzindo uma política de suporte à segurança para Kotlin
- Cada linha de lançamento do Kotlin (por exemplo, 2.4.x) é suportada para correções de segurança por 18 meses a partir da data de lançamento de sua versão .0.
- Correções de segurança são retrocombinadas em todas as linhas de lançamento dentro de um período ativo de suporte e publicadas como o mais recente patch em cada linha.
- Espaço: o artefato kotlin-stdlib do runtime JVM.
Por que a biblioteca padrão da JVM especificamente? A principal preocupação que esta política aborda é código em execução na produção no JVM – a camada de tempo de execução contra a qual cada aplicativo Kotlin do JVM se liga e envia para seus servidores. É essa camada que os processos de conformidade e revisão de segurança focam quando avaliam a frescura das dependências, e é onde o suporte documentado realmente desbloqueia decisões. Ferramentas de tempo de compilação – o compilador, plugins Gradle e Maven – ficam na infraestrutura de build, não no runtime de produção, e são governadas de maneira diferente. Esta política alinha-se exatamente onde o suporte é necessário.
Como patches são lançados. Quando um problema de segurança é encontrado e corrigido, a correção é primeiro adicionada a um lançamento baseado na versão mais recente da linha do Kotlin e depois retrocombinada em todas as outras linhas ainda em suporte. Patches são publicados como o próximo patch release em cada linha afetada – por exemplo, se 2.4.20 é a versão estável atual na linha de lançamento 2.4, o próximo patch release será 2.4.21. Cada linha de lançamento mantém sua própria numeração de versão, então uma equipe que tenha qualificado 2.4 para produção pode permanecer em 2.4 para receber a correção, sem cruzar para uma nova linha de lançamento.
Lançamentos são enviados juntos. Cada patch de segurança é um lançamento completo do Kotlin – passa pelo pipeline de lançamento padrão e envia o conjunto completo de artefatos. Você atualiza uma versão do Kotlin em sua build e recebe a biblioteca padrão corrigida. Patches para todas as linhas suportadas afetadas são publicados simultaneamente.
CVE e aviso. Problemas de segurança recebem identificadores CVE onde aplicável e são publicados na página JetBrains Fixed Security Issues através do processo de aviso de segurança estabelecido da JetBrains.
A política se aplica a linhas do Kotlin lançadas desde o lançamento em diante (2.4 e posterior). Linhas anteriores permanecem no modelo anterior e não são cobertas retroativamente.
A lista atual de linhas de lançamento suportadas, suas datas de fim do suporte e a versão patch mais recente em cada linha é mantida em uma página dedicada na página kotlinlang.org. Essa página é a referência canônica para quais versões são atualmente suportadas.
Como uma linha de lançamento evolui
A política é mais fácil de seguir se você observar como uma linha de lançamento evolui desde o primeiro lançamento (.0) até o fim do suporte. Abaixo está um exemplo do que isso parece para 2.4 (com uma cronologia aproximada; as datas exatas não importam neste exemplo).
- A versão 2.4.0 é lançada. A linha 2.4 entra no período de suporte à segurança de 18 meses.
- Um relatório de segurança chega logo após o lançamento. O correção de segurança é adicionado à linha de lançamentos e é disponibilizado como 2.4.10. (Observação: a slot x.x.10 segue a convenção estabelecida pelo Kotlin para a primeira correção de bug em x.x.0.)
- Meses depois, a versão 2.4.20 é lançada como o próximo lançamento regular na linha 2.4. Ela inclui todas as correções de segurança anteriores.
- Um novo relatório de segurança chega após a versão 2.4.20. A correção de segurança é disponibilizada como 2.4.21. A última correção na linha 2.4 é agora 2.4.21 – a versão que as equipes devem estar usando.
- A versão 2.5.0 é lançada, abrindo sua própria janela de 18 meses. A linha 2.4 ainda está em suporte; ambas as linhas recebem retroportas de segurança.
- A versão 2.6.0 é lançada, abrindo a linha 2.6. Neste ponto, a 2.5 já teve seu próprio ciclo regular e está na versão 2.5.20; a 2.4 ainda está em suporte na versão 2.4.21. Um novo problema de segurança é relatado e confirmado. A correção é adicionada à última versão estável como 2.6.10, e simultaneamente retroportada para as linhas ainda suportadas 2.5 e 2.4 como 2.5.21 e 2.4.22 – todas as três versões são lançadas no mesmo dia.
- A linha 2.4 atinge o fim do suporte 18 meses após a versão 2.4.0. As correções de segurança para essa linha param.
Dois pontos práticos: primeiro, você pode permanecer na linha de lançamento que qualificou para produção e ainda receber as correções de segurança – não é necessário pular versões. Segundo, quando uma correção é publicada, ela fica disponível em todas as linhas suportadas ao mesmo tempo. Não há um “a linha mais recente foi corrigida, sua linha mais antiga vai recebê-la eventualmente”.
O que não está mudando
- A política de lançamento do Kotlin permanece inalterada. Correções de bugs, recursos da linguagem e bibliotecas, e melhorias de desempenho continuam a ser disponibilizadas em novos lançamentos como sempre fizeram. Linhas mais antigas ainda suportadas recebem apenas retroportas de segurança.
- Cada novo lançamento do Kotlin continua sendo a base recomendada para novos projetos. A janela de suporte à segurança existe para organizações que precisam permanecer em uma linha menor específica por razões de conformidade – ainda não recomendamos adiar as atualizações.
FAQ e onde ir a seguir
P: O que conta como uma correção de segurança sob essa política? R: Problemas com impacto de segurança confirmado – vulnerabilidades do tipo rastreadas por CVE, onde o uso documentado e corretamente da API leva a um impacto de segurança. Abusos de nível de aplicativo e problemas causados pelo fornecimento de entrada de usuário não validada para APIs do stdlib não são cobertos.
P: Eu preciso atualizar para receber uma correção de segurança? R: Só dentro da sua linha de lançamento. A correção é disponibilizada como o próximo patch naquela linha – por exemplo, 2.4.20 → 2.4.21. Você não precisa pular para uma versão mais nova para recebê-la.
P: Onde posso ver quais linhas estão atualmente suportadas? R: Na página dedicada de suporte no kotlinlang.org. Você pode encontrar o link abaixo.
P: Minha equipe usa bibliotecas que dependem de uma versão diferente da biblioteca padrão. Isso importa? R: Sim. Apenas uma versão do kotlin-stdlib acaba no classpath após a resolução de dependências, e qual versão específica isso é depende da sua ferramenta de construção. O Gradle resolve para a maior versão solicitada entre todas as suas dependências diretas e transitivas – então se uma dependência transitiva puxar uma nova biblioteca padrão, essa nova versão será a que está rodando, não a corrigida que você configurou na sua build. O Maven usa