Política de lançamento do Godot
Godot's release policy is in constant evolution. The description below provides a general idea of what to expect, but what will actually happen depends on the choices of core contributors and the needs of the community at a given time.
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.For example, porting Godot projects from Godot 3.x to Godot 4.x requires running the project through a conversion tool, and then performing a number of further adjustments manually for what the tool could not do automatically.
The
minorversion is incremented for feature releases that do not break compatibility in a major way. Minor compatibility breakage in very specific areas may happen in minor versions, but the vast majority of projects should not be affected or require significant porting work.This is because Godot, as a game engine, covers many areas like rendering, physics, and scripting. Fixing bugs or implementing new features in one area might sometimes require changing a feature's behavior or modifying a class's interface, even if the rest of the engine API remains backwards compatible.
Dica
Upgrading to a new minor version is recommended for all users, but some testing is necessary to ensure that your project still behaves as expected.
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.
We call major.minor combinations stable branches. Each stable branch
starts with a major.minor release (without the 0 for patch) and is
further developed for maintenance releases in a Git branch of the same name
(for example patch updates for the 4.0 stable branch are developed in the
4.0 Git branch).
Linha do tempo do suporte à versão
Stable branches are supported at least until the next stable branch is released and has received its first patch update. In practice, we support stable branches on a best effort basis for as long as they have active users who need maintenance updates.
Whenever a new major version is released, we make the previous stable branch a long-term supported release, and do our best to provide fixes for issues encountered by users of that branch who cannot port complex projects to the new major version. This was the case for the 2.1 branch, and is the case for the 3.x branch.
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.5 (master) |
Q3 2025 (estimate) |
|
Godot 4.4 |
March 2025 |
|
Godot 4.3 |
August 2024 |
|
Godot 4.2 |
November 2023 |
|
Godot 4.1 |
July 2023 |
|
Godot 4.0 |
March 2023 |
|
Godot 3.7 (3.x) |
Sem previsão por enquanto |
|
Godot 3.6 |
September 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 do Godot 3 para o Godot 4 para instruções sobre como migrar um projeto de Godot 3.x para 4.x.
Which version should I use for a new project?
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 do Godot 3 para o 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?
While Godot contributors aren't working under any deadlines, we strive to publish minor releases relatively frequently.
In particular, after the very long release cycle for 4.0, we are pivoting to a faster-paced development workflow, 4.1 released 4 months after 4.0, and 4.2 released 4 months after 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
When modifying a method's signature in any fashion (including adding an optional parameter), a GDExtension compatibility method must be created. This ensures that existing GDExtensions continue to work across patch and minor releases, so that users don't have to recompile them. See Handling compatibility breakages for more information.