← Blog

Por que o Turian 2.0.0 é uma versão MAIOR com apenas 1 mudança MENOR

Por que o Turian 2.0.0 é uma versão MAIOR com apenas 1 mudança MENOR

2026-07-18

O Turian 2.0.0 chegou. Se um "2.0" faz você esperar uma keynote, um editor todo redesenhado e uma centena de tópicos na lista de novidades, esta não é essa versão — e esse é exatamente o ponto. Esta versão contém uma única mudança de destaque, e ela é incompatível com versões anteriores. Esse é o único motivo pelo qual o número da versão passou de 1 para 2.

O que motivou a mudança de versão

Até a v1.17, o importador de glTF/GLB do Turian tinha uma limitação: ele processava apenas a primeira primitiva do primeiro mesh de um arquivo, descartando silenciosamente todo o restante. Isso funciona para um cubo, mas não para modelos reais, que normalmente possuem dezenas de meshes e materiais.

A Issue #45 resolveu esse problema. Agora os modelos importados processam todas os mesh e todas as primitivas, vinculando cada submeshes ao seu respectivo material. Para isso, foram necessárias três mudanças coordenadas:

  • O TMSH (nosso formato interno de mesh) ganhou uma tabela de submeshes, contendo os intervalos de índices e os materiais de cada primitiva dentro de um único buffer compartilhado de vértices e índices.
  • O MeshRendererComponent trocou o campo material por um vetor materials.
  • Os arquivos de cena também trocaram o campo material_guid por um vetor material_guids.

Essa última mudança afeta diretamente o que o Turian grava nos arquivos de cena do seu projeto. Uma cena salva pela versão 2.0.0 já não é totalmente compreendida pelo Turian 1.x. Pela nossa política de versões, isso caracteriza uma mudança incompatível — e mudanças incompatíveis significam uma nova versão "MAIOR". Não esperamos uma versão anual. Não acumulamos mudanças não relacionadas até haver conteúdo suficiente para justificar um grande anúncio. A mudança ficou pronta, então a versão mudou.

Por que fazemos versões dessa forma

Muitos engines tratam a versão como uma marca. Unity 6, Unreal 5, Godot 4 — cada número representa anos de trabalho acumulado, uma longa lista de novos recursos e, inevitavelmente, uma grande quantidade de mudanças incompatíveis.

É comum que equipes escolham uma versão do engine no início do projeto e nunca mais a atualizem, justamente porque o custo de atravessar uma dessas fronteiras de versão é difícil de prever. Esses "penhascos de atualização" raramente surgem da noite para o dia. Normalmente são o resultado de dezenas de mudanças incompatíveis adiadas e finalmente agrupadas em uma única "grande versão".

O Turian segue a direção oposta. O número da versão não é um evento de marketing. Ele é um indicador de compatibilidade.

O que você ganha

As migrações chegam uma de cada vez, enquanto a mudança ainda é pequena e está fresca na memória. O guia de migração da versão 2.0.0 cabe em uma única página e leva poucos minutos para ser seguido. O número da versão passa a ser honesto: quando a versão MAIOR muda, você sabe que vale a pena ler o guia de migração. Quando ela não muda, você sabe que seu projeto continua compatível com o código existente, mesmo depois de dezenas de novas versões. E, como as mudanças incompatíveis são publicadas assim que ficam prontas, não existe pressão para acumulá-las até uma futura "janela permitida" — exatamente a dinâmica que acaba criando atualizações dolorosas em outras plataformas.

Existe ainda outra vantagem, menos óbvia: cada mudança incompatível permanece localizada. O motivo da mudança ainda está claro para todos, a migração é pequena e focada, e as discussões giram em torno de uma única decisão de projeto, em vez de dezenas de mudanças sem relação entre si. Atualizar deixa de ser um projeto próprio, que exige semanas de planejamento e análise de riscos, para se tornar apenas mais uma tarefa rotineira de engenharia.

Isso também favorece um design melhor das APIs. Saber que compatibilidade é importante — mas não absoluta — nos permite evoluir uma API quando o benefício de longo prazo supera claramente o custo da migração. A alternativa seria preservar decisões tomadas por acidente para sempre, simplesmente porque alterá-las teria de esperar pela mítica "próxima grande versão".

O que você perde

Os números das versões deixam de ser memoráveis. Em algum momento existirão um Turian 7 e um Turian 12, e esses números, por si só, não significarão muita coisa. Um "2.0" parece muito maior do que realmente é — motivo pelo qual este artigo existe. Você também encontrará momentos de migração com mais frequência, embora cada um deles seja propositalmente pequeno.

Para nós, essa troca vale muito a pena.

Hoje e amanhã

Também é justo dizer que o Turian ainda está dando seus primeiros passos. Hoje existem poucos usuários e ainda não há produções comerciais utilizando o engine, então naturalmente o impacto imediato dessa política é pequeno.

Mas esse não é o motivo pelo qual a adotamos.

O objetivo é criar hábitos de engenharia previsíveis antes que o ecossistema cresça. À medida que mais projetos — e, futuramente, produções comerciais — passarem a depender do Turian, cada mudança incompatível exigirá naturalmente um planejamento muito mais cuidadoso. Será preciso avaliar melhor o momento certo, o custo da migração, o feedback da comunidade e se o benefício realmente justifica interromper a compatibilidade dos projetos existentes.

A filosofia permanece exatamente a mesma. O que aumenta é o critério necessário para aprovar uma mudança incompatível.

O Turian também ainda não oferece uma versão LTS ou qualquer outro tipo de ramo de estabilidade de longo prazo.

Neste estágio do projeto, manter múltiplas versões acrescentaria complexidade sem trazer benefícios proporcionais. O engine ainda evolui rapidamente, a comunidade é pequena e o processo de desenvolvimento precisa refletir essa realidade.

Conforme o projeto amadurecer, o processo de lançamento amadurecerá junto. Suporte de longo prazo, garantias estendidas de compatibilidade ou outros mecanismos de estabilidade podem perfeitamente se tornar a escolha correta no futuro. O processo atual foi pensado para o Turian de hoje, não porque acreditamos que ele deva permanecer assim para sempre.

Recursos não esperam anúncios

Uma consequência dessa filosofia é que numeração de versões e comunicação passam a ser duas coisas diferentes.

Novos recursos, melhorias e correções de bugs continuam chegando em versões regulares exatamente como antes. Você pode decidir atualizar porque deseja uma melhoria no importador, um novo renderizador ou uma nova ferramenta para o estúdio. Ou simplesmente atualizar para receber correções de bugs e ignorar completamente os novos recursos adicionados. O ritmo de evolução do engine não muda só porque houve uma nova versão MAIOR.

Mas, curiosamente, seguimos quase a lógica oposta quando o assunto é comunicação.

Em vez de publicar um artigo para cada recurso individual, preferimos reunir essas novidades periodicamente em resumos maiores, como o Resumo de Junho de 2026. Esses artigos contam a história da evolução do engine de forma mais coesa, conectando várias melhorias em uma única narrativa útil tanto para usuários quanto para curiosos e veículos especializados.

Enquanto isso, o desenvolvimento do dia a dia já acontece exatamente onde desenvolvedores esperam encontrá-lo: commits, merge requests, issues, notas de versão e discussões. Isso mantém a comunicação técnica imediata sem transformar o blog em uma sequência interminável de pequenos anúncios desconectados.

Os números de versão respondem a uma pergunta:

"Preciso me preocupar com compatibilidade?"

Os artigos de resumo respondem a outra:

"O que mudou recentemente no Turian?"

Separar essas duas respostas torna ambas mais claras.

O que você precisa fazer

Muito pouco:

  1. Atualize para a versão 2.0.0. Os meshes processadas serão reconstruídos automaticamente na primeira vez em que forem abertos.
  2. Execute turian-cli migrate <project>. Esse comando reescreve os arquivos de cena que ainda utilizam o antigo campo material_guid. As cenas antigas continuam sendo carregadas normalmente, mas agora emitem um aviso.
  3. Se o seu código acessava MeshRendererComponent.material, utilize materials[0] em seu lugar (junto com material_count, quando apropriado).

O passo a passo completo — incluindo a única coisa que você não deve fazer (salvar cenas com o Turian 2.0.0 e depois reabrir o projeto na versão 1.x) — está disponível no guia de migração da versão 2.0.0.

Como bônus, modelos que sempre possuíram múltiplos meshes e materiais agora passam a ser importados corretamente. Se você já carregou algum modelo que parecia misteriosamente incompleto, esta versão provavelmente resolve esse problema.

#release#announcement#engine