Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Política de lançamento do Godot
A política de lançamento da Godot está em constante evolução. O que está descrito abaixo pretende dar uma ideia geral do que esperar, mas o que realmente acontecerá depende das escolhas dos principais colaboradores e das necessidades da comunidade em um determinado momento.
Controle de versão do Godot
Godot segue livremente o Versionamento Semântico com um sistema de versionamento maior.menor.correção, embora com uma interpretação de cada termo adaptada à complexidade de um Engine para jogos:
A versão
majoré incrementada quando grandes quebras de compatibilidade acontecem, o que implica um trabalho significativo de portabilidade para mover projetos de uma versão principal para outra.Por exemplo, para portar projetos do Godot 3.x para o Godot 4.x, é necessário processar o projeto por meio de uma ferramenta de conversão e, em seguida, realizar manualmente uma série de ajustes adicionais para o que a ferramenta não conseguiu fazer automaticamente.
A versão
minoré incrementada para lançamentos de recursos que não quebram a compatibilidade de forma significativa. Pequenas quebras de compatibilidade em áreas muito específicas podem acontecer em versões secundárias, mas a grande maioria dos projetos não deve ser afetada ou exigir um trabalho significativo de portabilidade.Isso ocorre porque o Godot, como motor de jogos, abrange diversas áreas, como renderização, física e scripts. Corrigir bugs ou implementar novos recursos em uma área pode, às vezes, exigir a alteração do comportamento de um recurso ou a modificação da interface de uma classe, mesmo que o restante da API do motor permaneça compatível com versões anteriores.
Dica
Atualizando para uma nova versão minor é uma ação recomendada para todos os usuários, mas testes serão necessários para certificar de que seu projeto ainda se comporte de maneira esperada na nova versão.
A versão
patché incrementada para lançamentos de manutenção que focam em corrigir bugs e problemas de segurança, implementar novos requisitos para suporte de plataformas, e portar melhoras presentes em versões futuras para a versão atual. Lançamentos patch são compatíveis com versões anteriores.Versões patch podem incluir pequenas novas funcionalidades que não impactam a API existente, e então não têm risco de impactar projetos existentes.
Dica
A atualização para novas versões de patch é, portanto, considerada segura e fortemente recomendada para todos os usuários de uma determinada ramificação estável.
Chamamos combinações major.minor de ramos estáveis. Todo ramo estável começa com um lançamento major.minor (sem o 0 para patch) e é desenvolvido ainda mais para lançamentos de manutenção num ramo do Git do mesmo nome (por exemplo atualizações patch para o ramo estável 4.0 são desenvolvidas no ramo Git 4.0).
Linha do tempo do suporte à versão
Ramos estáveis têm suporte oficial pelo menos até o próximo ramo estável ser lançado e receber a primeira atualização patch. Em prática, suportamos ramos estáveis na base do melhor esforço por tanto tempo quanto ainda existirem usuários ativos que necessitam de atualizações de manutenção.
Sempre que uma nova versão principal é lançada, tornamos a ramificação estável anterior uma versão com suporte de longo prazo e fazemos o nosso melhor para fornecer correções para problemas encontrados por usuários desse ramo que não conseguem migrar projetos complexos para a nova versão principal. Este foi o caso do ramo 2.1, e é o caso do ramo 3.x.
Em uma determinada série de versões secundárias, apenas a versão de patch mais recente recebe suporte. Se você tiver problemas ao usar uma versão de patch mais antiga, atualize para a versão de patch mais recente dessa série e teste novamente antes de relatar um problema no GitHub.
Versão |
Data de lançamento |
Nível de suporte |
Godot 4.7 (principal) |
Q2/Q3 2026 (estimado) |
Desenvolvimento |instável|. Recebe novos recursos, melhorias de usabilidade e desempenho, bem como correções de bugs, enquanto está em desenvolvimento. |
Godot 4.6 |
Janeiro de 2026 |
|
Godot 4.5 |
Setembro de 2025 |
|
Godot 4.4 |
Março de 2025 |
|
Godot 4.3 |
Agosto de 2024 |
|
Godot 4.2 |
Novembro de 2023 |
|
Godot 4.1 |
Julho de 2023 |
|
Godot 4.0 |
Março de 2023 |
|
Godot 3.7 (3.x) |
Sem previsão por enquanto |
|
Godot 3.6 |
Setembro de 2024 |
|
Godot 3.5 |
Agosto 2022 |
|
Godot 3.4 |
Novembro de 2021 |
|
Godot 3.3 |
Abril de 2021 |
|
Godot 3.2 |
Janeiro de 2020 |
|
Godot 3.1 |
Março de 2019 |
|
Godot 3.0 |
Janeiro de 2018 |
|
Godot 2.1 |
Julho de 2016 |
|
Godot 2.0 |
Fevereiro de 2016 |
|
Godot 1.1 |
Maio de 2015 |
|
Godot 1.0 |
Dezembro de 2014 |
|
Legenda:
Suporte completo -
Suporte parcial -
Sem suporte (end of life) -
Versão de desenvolvimento
Versões de pré-lançamento do Godot não têm a intenção de serem usadas em produção e são disponibilizadas apenas para propósitos de teste.
Ver também
Veja Atualizando de Godot 3 para a Godot 4 para instruções sobre como migrar um projeto de Godot 3.x para 4.x.
Qual versão eu deveria usar para um novo projeto?
Recomendamos usar o Godot 4.x para novos projetos, já que a série Godot 4.x será suportada muito depois que 3.x parar de receber atualizações no futuro. Uma ressalva é que muita documentação de terceiros ainda não foi atualizada para Godot 4.x. Se você tem que seguir um tutorial projetado para Godot 3.x, recomendamos manter Atualizando de Godot 3 para a Godot 4 aberto em uma guia separada para verificar quais métodos foram renomeados (se você obter um erro de script ao tentar usar um nó específico ou método que foi renomeado em Godot 4.x).
Se o seu projeto requer uma funcionalidade que está faltando no 4.x (como GLES2/WebGL 1.0), você deve usar Godot 3.x para um novo projeto.
Devo atualizar meu projeto para usar novas versões do Godot?
Nota
Atualizar um software enquanto trabalha em um projeto é inerentemente arriscado, então considere se é uma boa ideia para o seu projeto antes de tentar uma atualização. Além disso, faça backups de seu projeto ou use controle de versão para evitar a perda de dados no caso de a atualização correr mal.
Dito isto, fazemos o nosso melhor para manter lançamentos menores e especialmente patchs compatíveis com projetos existentes.
A recomendação geral é que você atualize seu projeto para seguir lançamentos de patch novos, como atualizar da versão 4.0.2 para a 4.0.3. Esta prática assegura que atualizações de correção de bug, de segurança e suporte a plataforma estejam em dia. Você também tem suporte contínuo, já que apenas o último patch recebe suporte nas platformas oficiais de comunidade.
Para lançamentos menores, você deve determinar quando é uma boa ideia atualizar, baseado no seu próprio caso. Nós colocamos bastante empenho em fazer o processo de atualização o mais invisível possível, porém alguma mudanças bruscas talvez estejam presentes em lançamentos menores, ao lado de maiores riscos de regressão. Algumas correções incluídas em lançamentos menores podem também mudar o comportamento esperado de uma classe, afim de corrigir algum bug. Isso é ainda mais forte em classes marcadas como experimental na documentação.
Lançamentos maiores trazem diversas novas funcionalidade, mas também removem funcionalidade antes existentes, e podem aumentar os requisitos de hardware. Eles também requerem maior esforço para a atualização em comparação com lançamentos enores. Como resultado, recomendamos que você fique com a versão maior em que começou o seu projeto, se estiver feliz com como este funciona atualmente. Por exemplo, se seu projeto foi iniciado na versão 3.5, recomendamos que atualize para a versão 3.5.2 e possivelmente 3.6 no futuro, mas não para a 4.0+, a não ser que seu projeto realmente precise das funcionalidades adicionadas na versão 4.0+.
Quando será o próximo lançamento?
Embora os colaboradores do Godot não estejam trabalhando sob nenhum prazo, nos esforçamos para publicar pequenos lançamentos com relativa frequência.
Em particular, após o muito longo, ciclo de lançamento para a versão 4.0, estamos nos virando para um fluxo de trabalho de desenvolvimento mais rápido, a versão 4.1 foi lançada 4 meses após a versão 4.0 e a versão 4.2 foi lançada 4 meses após a versão 4.1.
Lançamentos menores frequentes irão possiblitar-nos de entregar funcionalidades novas mais rápido (possivelmente como experimental), obter feedback de usuário rapidamente, e melhorar estas funcionalidades e suas usabilidades. Igualmente, a experiência de usuário geral será melhorada mais passadamente, com um caminho mais rápido para usuários finais.
Os lançamentos de manutenção (patch) são lançados conforme necessário com ciclos de desenvolvimento potencialmente mais curtos, para fornecer aos usuários do ramo estável atual as últimas correções de bugs para suas necessidades de produção.
Atualmente, não há uma data de lançamento planejada para a próxima versão menor 3.x, a 3.7. A versão estável atual, 3.6, pode ser o último branch estável do Godot 3.x. O Godot 3.x é mantido com base no melhor esforço, enquanto os colaboradores continuarem a mantê-lo.
Quais são os critérios de compatibilidade através das versões da engine?
Nota
Esta sessão visa ser utiilizada por contribuidores para determinar quais mudanças são seguras para um determinado lançamento. A lista não é exaustiva; apenas delineia as situações mais comuns ecnontradas durante o desenvolvimento da Godot.
As seguintes mudanças são aceitáveis em lançamentos de correção:
Corrigir um bug de uma forma que não tenha um impacto negativo grande na maioria dos projetos, tais como bugs visuais ou de física. A engine de física da Godot é não determinística, portanto correções de bugs de física não são consideradas uma quebra de compatibilidade. Se corrigir um bug tem um impacto negativo que poderia afetar diversos projetos, deve ser feito de forma opcional (p.e.: utilizando um parâmetro de configuração de projeto ou método separado).
Adicionar um novo parâmetro adicional a um método.
Ajustes de baixo-porte na usabilidade do editor.
Note que tendemos a ser mais conservadores com as correções que permitimos em cada lançamento de correção subsequente. Por exemplo, 4.0.1 talvez receba correções mais impactantes que a versão 4.0.4 receberia.
As mudanças a seguir são aceitáveis em lançamentos menores, mas não em lançamentos de correção:
Novas funcionalidades significativas.
Renomear um parâmetro de um método. Em C#, parâmetros de métodos podem ser passados pelo nome (mas não em GDScript), resultando na quebra de alguns projetos que utilizem C#.
Descontinuar um método, variável membro ou classe. Isto é feito adicionando-se uma marcação de descontinuação em sua referência de classe, oque irá aparecer no editor. Quando um método é marcado como descontinuado, ele é agendado para remoção no próximo lançamento principal.
Mudanças que afetam os visuais do tema padrão do projeto.
Correções de bugs que mudam significativamente o comportamento ou a saída, com a intenção de atender melhor as expectativas dos usuários. Em comparação, nos lançamentos de correção, podemos preferir a manutenção de um comportamento com bugs para não quebrar projetos existentes, que podem contar com este bug ou implementar correções.
Otimizações de performance que resultem em mudanças visuais.
As mudanças a seguir quebram a compatibilidade e podem ser implementadas apenas em lançamentos maiores:
Renomear ou remover um método, variável membro ou classe.
Modificar a árvore de heranças de um nó, fazendo com que herde de outra classe.
Mudar o valor padrão de uma preferência de projeto de forma que afete projetos existentes. Para afetar apenas projetos novos, o gerenciador de projetos deve escrever um
project.godotmodificado.
Já que a versão 5.0 do Godot ainda não foi planejada, nós atualmente desencorajamos mudanças que quebrem a compatibilidade como estas.
Nota
Ao modificar a assinatura de um método de qualquer forma (incluindo adicionar um parâmetro opcional), um método de compatibilidade GDExtension deve ser criado. Isso garante que as GDExtensions(ExtensõesGD) existentes continuem funcionando em patches e em pequenos lançamentos, para que os usuários não precisem recompilá-las. Veja Handling compatibility breakages para mais informações.