Você fechou o terminal em 2026 rodando MySQL 8.4, foi dormir, e acordou com gente falando em MySQL 28.4. Antes de ligar pro suporte achando que perdeu uma década de releases, respira. Você não congelou no tempo, e o MySQL não ganhou vinte versões inteiras de uma vez. O que mudou foi a forma de contar as versões.
A Oracle anunciou duas mudanças importantes recentemente: um novo modelo de release (versionamento por calendário) e uma “nova fase” de engajamento com a comunidade. A primeira explica o 28.4 do título. A segunda é a parte em que vale manter a sobrancelha levantada. Vamos por partes.
O número assusta, a explicação acalma
A partir da próxima release Innovation, o número da versão passa a ser uma data. O formato é YY.M: os dois últimos dígitos do ano, seguidos do mês sem zero à esquerda. Janeiro é 1, abril é 4, julho é 7, outubro é 10. Só isso.
Ou seja, 28.4 não é “a versão 28 do MySQL”. É a linha que nasce em abril de 2028. O número grande não veio de vinte anos de features acumuladas, veio do calendário.
Innovation e LTS, agora com a data no crachá
As duas trilhas que você já conhece continuam. Innovation é onde entram as features novas, em ciclo curto, pra quem gosta de experimentar com novas features. LTS é a linha estável, com suporte longo, que é onde a maioria da produção deveria estar. O que muda é só o nome de cada uma.
A virada acontece na próxima release Innovation, prevista para julho de 2026, que já nasce como 26.7.0. O 9.7 é a última a usar a numeração antiga. Depois disso, o nome conta a história sozinho:
|
1 2 3 4 |
<span class="c-num">26.7.0</span> <span class="c-com"># Innovation de julho de 2026</span> <span class="c-num">26.10.0</span> <span class="c-com"># Innovation de outubro de 2026</span> <span class="c-num">28.4.0</span> <span class="c-com"># LTS que comeca em abril de 2028</span> <span class="c-num">28.4.10</span> <span class="c-com"># ainda o LTS de abril/2028, so o 11o patch</span> |
O detalhe esperto está na linha de baixo. Quando uma versão é coroada como LTS, o prefixo YY.M congela pelo resto do ciclo de vida dela. O LTS de abril de 2028 vai cuspir 28.4.0, 28.4.1, 28.4.2 e assim por diante, mesmo quando o calendário já marcar 2030. Muda o número do patch, nunca o prefixo. É o que faz 28.4.10 continuar dizendo “sou o LTS de abril de 2028” anos depois.
28.4.x qualquer? 28 é o ano (2028), 4 é o mês (abril), x é o patch. Pegou um 26.10.0? Outubro de 2026. A versão virou um carimbo de data, e isso é de propósito.E eu, no meu 8.0 de estimação?
Aqui mora a parte prática. O 8.0 já encerrou o ciclo de suporte, então a resposta honesta é: sim, é hora de sair. Não por causa do número novo, mas porque ficar numa versão sem patches de segurança é o tipo de economia que cobra juros depois (e bem altos).
O 8.4 é o LTS atual e segue firme com suporte de longo prazo. Se você está nele, está tudo bem. E o tal 28.4 do título? Ainda não existe. É só o nome que o próximo LTS vai ter quando abril de 2028 chegar.
A regra de ouro não mudou: LTS pra produção, Innovation pra quem quer testar o que vem por aí. Você não precisa correr atrás de toda release Innovation. Precisa só saber ler o número, o que agora é bem mais fácil.
A outra notícia: a comunidade entra (em parte) na roda
No mesmo pacote, a Oracle anunciou uma “próxima fase” de engajamento com a comunidade. Os pontos concretos:
- Um Steering Committee formado de início por AWS, Google Cloud e Oracle, mais alguns usuários. A Microsoft, curiosamente, ficou de fora.
- Contribuidores da comunidade podem virar committers, revisando mudanças e ajudando a manter a qualidade do código.
- O GitHub vira o hub central: roadmap tocado via GitHub Projects, discussões públicas e tracking de contribuição no mesmo lugar.
- O ritmo de Early Access continua. Os dois builds antecipados do 9.7 somaram quase 11 mil downloads, o que para um pré-lançamento de banco de dados é bastante gente curiosa.
- O Contributor Summit de maio de 2026 teve mais de 20 sessões, quase metade apresentada por gente de fora da Oracle.
Lido assim, é uma lista boa. Mais transparência, mais portas abertas, mais convite pra participar. O tom mudou, e isso ninguém nega.
O ceticismo
Agora a parte em que a gente puxa a cadeira e fala baixo. A recepção da comunidade foi de aplauso com a mão no bolso. A recém-formada OurSQL Foundation e gente como Peter Zaitsev, da Percona, fizeram a pergunta óbvia: o que disso tudo é vinculante?
A comunidade é envolvida em caráter consultivo. Não há nada vinculante nesse sentido.
Traduzindo: o comitê aconselha, mas quem decide ainda é a Oracle. A dúvida que fica é se uma proposta da comunidade que contrarie o interesse comercial da Oracle seria aceita, e se vale o esforço de contribuir para um sistema que uma única empresa controla de ponta a ponta.
Por enquanto, temos um tom melhor e um novo comitê. O teste de verdade vem na primeira vez em que a comunidade pedir algo que a Oracle preferiria não conceder.
Claramente ainda existe bastante ceticismo por parte da comunidade, mas a Oracle parece disposta a provar que vale a pena dar mais este voto de confiança.
Então, atualizo?
O novo número é mais assustador do que o upgrade em si. Resumindo a ópera:
- Está no 8.0? Planeje a saída. O suporte gratuito acabou, e isso não tem a ver com versionamento, tem a ver com não ficar sem patch.
- Está no 8.4? Você está no LTS atual. Pode respirar e acompanhar de longe.
- Curte testar o futuro? As releases Innovation (a próxima já sai como
26.7.0) e os Early Access no GitHub são pra você.
E quando 2028 chegar, o próximo LTS vai se chamar 28.4, e você vai bater o olho e entender o nome na hora. Que é, no fim, exatamente o ponto de toda essa mudança. Continua sendo o mesmo MySQL de sempre. Só que agora a versão te diz que dia é hoje.
Fontes
- A More Predictable MySQL Release Model: Calendar Versions, LTS, and Innovation — Oracle MySQL Blog
- The Next Phase of MySQL Community Engagement — Oracle MySQL Blog
- Oracle promises to open up MySQL governance, but the community wants guarantees — The Register
